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Introduction 


Mud, Sweat and Gears (MSG) is an off road racing game in which the player battles opposing vehicles 
and extremely challenging terrain — including moving ice, falling boulders, tornados, and treacherous 
jumps - to be the first to the finish. The game is designed for next generation consoles (specifically, the 
Sony PlayStation 2), and will take advantage of the next level of hardware to provide dynamic lights, 
real-time terrain deformations, realistic physics, high use of particle effects, high amounts of animated 
models, shadow effects. 


Technical Overview 


Platform — PlayStation 2 (a.k.a. PS2) 
Target Frame Rate — 60 fps 

Target Gold Master Candidate -— August 7, 2000 

Target Release Date — September 15, 2000 
Memory Map 

Sony OS/kernel 2mb 
Geometry data 16mb 
Cached textures 10mb 
Code footprint 2mb 
Sound buffer 2mb (SPU, off DRAM) 
Sound buffer (DRAM) 512k 
Physics data 8k 
Scene Manager (including data for 5000 objects) = ~128k 
Al data 16k 
Terrain Al data 32k 


Approximately 1 1/2 mb left over for expansion 


Staff 


Press Start, Management 


Paul Shaw President 

Ross Horman Project Manager, Producer 

Jim Tomasko Technical Director, Engineering Lead 
Scott Paterson Art Director 


Press Start, Engineering 


Jim Tomasko Scene Manager, animation, FMA, sound & music 
Carla Meninsky Rendering API, high level renderer, AI, terrain 
Carolyn Wales Physics, collisions, particle systems 

Doug Coward Menu systems, fonts, UI, input, binary tools 


Alexey Kadukin Tool chain, networking, memory management 
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Press Start, Art 


Scott Paterson Art Director, animation, modeling, storyboards, 

Bill Yeatts Modeling, animation, textures, storyboards 

Sean Spitzer Environment modeling, textures, animation, storyboards 
Scott Kinkaid UI, production work, textures, storyboards 

Lee Steg Illustration, design, modeling, textures, storyboards 

Yu Gu Object modeling, animation, textures 

Paul Shapiro Object modeling, animation, textures 


Interplay, Management 


Trish Wright Vice President of Product Development 
Jim Molitor Executive Producer 

Shawn Jacoby Producer 

David Sullivan Technical Director 

Rob Nesler Art Director 


Interplay, Programming 
John Morgan Low level renderer 


In addition to the low level renderer, Interplay is responsible for supplying the project with all sound 
assets (music, sound effects, voices) necessary for the creation of the game. 


Contact Information: 


Paul Shaw 408-962-1004 pshaw@pressstart.com 

Jim Tomasko 408-962-1006 jtomasko@pressstart.com 
Scott Paterson 408-962-1016 spaterson@pressstart.com 
Ross Horman 408-962-1005 rhorman@pressstart.com 

Jim Molitor 949-223-5838 dsullivan@interplay-usa.com 
Shawn Jacoby 949-223-5700 sjacoby@interplay-usa.com 
David Sullivan 949-223-5736 dsullivan@interplay-usa.com 
John Morgan 949-223-5736 jmorgan@interplay-usa.com 
Rob Nesler 949-223-5824 rnesler@interplay-usa.com 


Localization Considerations 


Some of the text is embedded art (such as title screen logos and the like). Any of this text that requires 
localization changes will require art rework. 


All other text will reside in a text file where all the text is indexed and can be changed easily. The ability 
for the text “boxes” to resize due to expanding word size will be used when possible. Character strings 
used for display purposes will be stored as DBCS wide strings (UNICODE). 


Frame rate timing for animation is done in floating point, and synchronized with time instead of frames 


per second, so conversion to PAL will be primarily an issue of screen resolution — provided that PAL PS2 
units output a different resolution than their NTSC counterparts. 
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Derivative Game Considerations 


Various parts of the game and tool chain are built to be reusable, especially for the task of making games 
based on 3D worlds. The 3D Studio MAX plug-in is built to be extensible for building 3D worlds and 
characters. Much of the specifics required to make a racing game are in configuration files that may or 
may not be reused at the end of MSG. The same design considerations have been included in the engine 
design to get reuse from the scene manager, memory manager, math library, error management, input 
management, sound, collision detection, timing, and API to the renderer. 


Portability considerations 


The majority of the core engine and Calliope™ plug-in for MAX have been designed with portability in 
mind. Areas such as the input manager and renderer have high level API's which allow ease of use in 
making all but the low level portions of them portable to other platforms (such as the PC) at a later date. 


The binary converter (which converts the MAX plug-in output to a format the engine may work with) is a 
candidate for rewrite for other platforms, as well as the actual geometry (polygon and texture data) 
format within the engine. Care has been taken to fully separate the actual model data format from the 
model’s “skeleton” and animation data to insure that geometric data is contained in a localized area of 
the engine code. 


One last major portability concern is the actual amount of model and AI data, (game specific vs. engine 
specific). If portability of MSG (as a game and not as an engine) is an issue in the future, the current plan 
is to add SKU specific tags on all the model data in the MSG 3D Studio files, where the artist may tag 
objects to be exported for one format and not another. This allows the artist to create a scene in which all 
objects are present for one platform, with some objects not present on others — sort of a platform 
implementation of LOD. 


Tools 

Art 

3D Studio MAX R3 — modeling, world building, animations, texturing 

Maya 2.5 — sculpting of primary terrain regions 

Animatek’s World Builder — modeling of trees and other terrain elements. 

Adobe Photoshop — creation of textures 

Debabelizer Pro — animated textures, super-paletting 

Programming 

MS Visual Studio 6.0 — tools, game and engine programming, at least until we have PS2 dev 
systems. 

MS Visual SourceSafe 6.0 — source control and asset management (If we end up doing PS2 


development under Linux we may have to change to Perforce or 
another version control system) 


PS2 development will be done with either the Sony supplied debugger /complier (GCC and GDB), the 
Metrowerks PS2 IDE, or the SN Systems PS2 IDE. Press Start intends on working entirely within a 
Windows environment unless the PS2 development tools for Windows are not in an acceptable condition. 
If the Windows tools are not acceptable, we will migrate to the most acceptable solution. 
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Major Components 


Scene Manager 


Animation 


AI (including terrain deformation) 


Renderer 


Camera System 


Jim Tomasko 

Jim Tomasko 

Carla Meninsky 

Carla Meninsky and John Morgan 
Doug Coward 


Physics Carolyn Wales 
Collision Detection Carolyn Wales 
Networking Alexey Kadukin 


Audio and Data Streaming 
Menus and UI Toolkit 

Input Handling 

Low Level Hardware Interface 
Art Tool Chain 


Particle System 


Jim Tomasko and Carolyn Wales 

Doug Coward 

Doug Coward 

Carolyn Wales and Carla Meninsky 

Alexey Kadukin, Jim Tomasko, and Doug Coward 
Carolyn Wales 


FMA (Jim Tomasko 
Memory Card Doug Coward 
Virtual File System Carolyn Wales 
Memory Management Alexey Kadukin 
Geometry Compression Carla Meninsky 


Sound & Music 


Jim Tomasko 


Instant Replay Doug Coward 
Special Effects Entire Technical Team 
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Scene Management 


The Scene Manager is responsible for running the main game loop, for determining basic LOD 
information needed for object processing, and for broadcasting any important messages (such as, “restart 
game”, or “stop game”) to the objects in the game. 


The main game loop is divided into five different time slices: 


> Get current time 
Poll the input devices 
Do AI! 


Do animation2 


VV V WV 


Render the scene 


Each object that has an AI (i.e., can “do” something) has a controller that is registered with the Scene 
Manager. The controllers are arranged in hierarchical order corresponding to the hierarchies within the 
objects being controlled. For instance, a gun attached to a person’s hand would have a controller that is a 
child of the parent controller. Please note that the things these controllers manage need not be geometric 
objects. There are controllers for sounds, cameras, lights, triggers, and anything else that has AI 
processing. 


The controllers contain, among other things, pointers to functions used for processing messages from the 
Scene Manager - the “Do AI” of step 3 is such a message. Since not all controllers need to be processed 
every loop, the top level of the hierarchy contains priority nodes which act as gateways to the controllers 
below. In general, the priority nodes contain counters and will allow their controllers to be processed 
every n times through the loop. 


The animation time-slice is also controlled through the controllers. The Scene Manager walks through 
the list of controllers, telling them to do their animations. Note that the child controllers are inhibited 
from the animation time-slice as the actual objects they point to are already hierarchically linked and will 
animate together naturally. 


The AI time-slice determines if an animation is playing and how much time to take when transitioning 
between animations, but the animation time-slice is responsible for setting up the matrices for that frame 
of animation, and interpolating between matrices if transitioning between two animation sequences. 
When the animation slice determines that the animation has finished, it sends a message to the through 
the controller notifying the AI. 


When the frame rate is threatening to drop below the target frame rate (or already has), the Scene 
Manager sets a flag that notifies the various controllers. The individual controllers and their Als are 
responsible for doing whatever is necessary to keep the frame rate up. At this point it is premature to say 
exactly what we might do, but options include switching to a lower level of detail for non-critical objects, 


' The term AI (above) is used in a general sense. Essentially, each object is given a chance to do whatever it feels is 
appropriate. That may be camera positioning, physics, collisions, setting which animation to play, and standard AI 
type tasks. AI for an object in the world is intended to generally be set up as a state machine, but there is no 
limitation imposed that requires this. 


* Each object has an opportunity to set itself up for the next frame of animation, if it is animating. 
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running the physics and collision engines less frequently, or simplifying processing of objects that are off 
screen. 


Risks - Low. 


The Scene Manager is relatively straightforward. Creation of the space-partitioning gems is potentially 
tedious, but is not a major risk in the game. The only real risk (and it is slight) is that the structure of the 
Scene Manager might prove too inflexible to support some of the real-time callback and interrupt 
functions that we need. 


Scene Manager Goals 
The scene manager has 5 primary goals: 


> Get the current project out on time as full featured as possible. 


» Toallow a very high level of re-use for not only possible sequels, but also for other games based 
upon 3D world environments. Every attempt has been made to insure that the scene manager 
only suffers from two dependencies, one is that it offers an operating system style environment 
for management of 3D worlds only; The other is that the 3D worlds take advantage of a particular 
space subdivision technique which is described later. The scene manager contains API calling 
prototypes which indicate when to render, when to get game controller data, along with other 
such calls, but does not actually perform these functions. 


>» To allow a small but powerful set of core code that performs in a consistent manner, allowing the 
major sections of the game to be reused with the goal of increasing reliability. 


> To allow for rapid prototyping of future games. 


» Tobe easy to understand and use. 


The scene manager is akin to the operating system of the game engine. This document attempts to detail 
not only the inner workings of the scene manager, but also attempts to stress the importance of a 
thoughtful integration of data and functions that will be added to produce a game with it. 


Major Components 
The scene manager is composed of the following components: 


Note: Appendix-A describes the tree mechanism, as well as a generalized traversal method. 


Core processing scheduler 


The scheduler may also be simply called the “main loop”. The scheduler is a single tasking poling loop 
which determines when to perform each of the main tasks, which are simulation time synchronization, 
game controller retrieval, AI processing, animation positioning, camera processing, and rendering. Each 
object in the world is handled through a callback mechanism which receives messages indicating what 
task they are to perform. 


Control Node Tree 


Each object in the world that is dynamic (any object that may be moved or has a “brain”) has a controller 
associated with it, and registers that controller with the controller tree. The controller tree is used to 
schedule AI processing and animation time slices. The controller tree is also used to send general 
broadcast messages to all controllers (such as game over). 
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Gem Tree 


The Gem Tree is a space partitioning tree, providing the highest level of space partitioning. This form of 
space partitioning provides the first level of culling for rendering and collision detection, as well as aids 
in “level of detail” control for dumbing down AI processing for objects out of view, and inhibiting 
animation processing. 


It is a collection of nodes that denote the space partitioning of the scene. Only the leaf nodes (the bottom 
nodes) may contain scene data in them. Among the data contained in a Gem is a list of other Gems that 
are visible from within the boundaries of the Gem, and a list of pointers pointing to the instances that are 
contained within the Gem. Other important data contained in the Gem is an Oct-tree representation of 
the static geometry in the region for the next level of render culling. As instance objects move within the 
world, they must ask “Am I still in the same Gem?” If the answer to that question is no, then the root 
level object of the instance must update the Gem it’s contained in. By knowing which dynamic objects 
are within a Gem, collision detection is localized, as well as bulk culling for rendering (where the 
renderer only looks at objects that the camera is in, and any objects that are visible to the current Gem). 
Real time lighting also benefits, as lights only effect the current Gem and Gems in the visibility list of the 
Gem. During the AI portion of the scene manager scheduling, which Gem an object is in may be used to 
change it’s priority for AI processing and inhibiting animation of the nodes (based upon which Gem the 
camera is in, and other game specific requirements). 


Template Tree 


The template tree holds templates for all objects that are either currently in the world, or that need to be 
kept around to make instances on the fly (such as explosion effects, where there is no time to get them 
from the storage media in time to use them). 


It contains the node hierarchies of each object that’s either currently instanced in the world, or objects 
tagged to not remove their templates when the last one is destroyed. The tree consists of one root, and 
each direct child of the root is a root object of a sub-tree which describes the hierarchy of a multi-node 
object. The nodes in the template tree contain pointers to non-dynamic data, such as the geometry for an 
object. If the object requires to modify it’s geometry, it must create a copy of the template that is unique | 
to it. The template also points to all the animation data per node, and all other read-only data. | 


Instance Tree 


The instance tree holds the objects that are instanced in the world. Any data that is common to all 
instances of a template merely point back to it’s template to save space. Only data such as an instances 
unique parameters, where it is in the world, it’s current animation state and the like are contained in the 
instance. 


It contains a root object, where each of it’s children are the root level object of an instance in the world. 
Note that instances may be linked to each other. This is shown in the block diagram where the instance 
made from the template with 2 nodes is linked to the instance with 3 nodes. One application of this 
would be a bird that has been hit by a moving car, and is trapped in the car’s bumper. This is done by 
linking the bird to the car so that as the car moves the bird goes along for the ride. 


Controller Tree | 


The controller tree contains a root object, where each of it’s direct children are priority control objects. 
The children of the priority control objects are the AI controllers for each instance that is dynamic in any 
way. Controllers are the objects that receive AI time slices. When a controller is evoked to perform it’s 
AI, it has a pointer back to the instance data so that it may manipulate the geometry of the instance (such 
as move it to a new location in world space). The priority nodes are used to manage processing load, and 
are configured on a game-by-game basis. One scheme is to process the priority one nodes each frame, | 
while processing the next priority every 10 frames, and never processing the last priority. Another | 
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scheme is process every frame (there’s not a terrible amount of controllers in a typical game), but to use 
the knowledge of the priority to perform a lower level of Al, such as in a race game the software may 
move cars out of the camera’s view to lower priority controllers, dependant on how far away it is. At the 
lowest priority the AI might just make a few simple predictions on where the car should be and just warp 
it there. 


Gem Space Partitioning 


Kay and Kajiya in SIGGRAPH 1986 introduced bounding volumes, which fitted the objects as tightly as 
possible, reducing the "void" volume. In their method the bounding volume consists of pairs of parallel 
planes, made to fit convex hulls of objects tightly. This is illustrated below: 


Two-dimensional representation only. 


Intersection testing is a simple generalization of the intersection box testing. In 2D a minimum of 2 pairs 
of "planes" (lines) is needed, in 3D at least 3 pairs are required. The number employed depends on the 
desired tightness of fit. 


In our implementation, space is partitioned hierarchically into regions known as gems, 18 sided 3- 
dimensional objects whose sides are aligned to one of the major axis, or 45 degrees off from a major axis. 


Each gem has a list of objects within it, as well as a list of other gems that are visible from the current 
gem. When it comes time to render, the Scene Manager assembles a visibility list of objects based upon 
visible gems, and sends this information to the high level renderer. 


Gems are created by hand by the artist or production assistant, and a careful choice of gems can greatly 
reduce the amount of processing overhead. 
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Scene Manager Data Organization 


This section describes the primary data organization for the scene manager. There are 4 trees based upon 
the RTree type (See Appendix A). The following block diagram shows the 4 data trees with sample data 
contained within them. 


Priority Node = Priority Node 


| 
| 


Controller 


Controller 


> Broken Lines show pointer connections between nodes that are not tree related. An arrowhead 
pointing to a node indicates that the node on the other end of the line points to it. Also note that 
some nodes point to each other, shown by an arrowhead on both sides of the line. 


>» The various cross-hatch is shown to indicate that there are 3 hierarchical objects in the template tree, 
one with 3 nodes, one with 2 nodes, and one with 1 node. Note the same patterns in the instance tree 
indicating that those nodes are instances of objects in the template tree. 


> Connections not shown are that each individual node in the instance tree points to it's template node 
in the template tree. 


11/3/99 ** PRESS START CONFIDENTIAL *** Page 10 of 65 


Technical Design Document 
Mud, Sweat & Gears: Off-road Madness Press Start, Inc. 


Scene Manager Task Processing 


The scene manager task processor contains a simple core (some call this the “main game loop”). The 
simplified task processor looks like the function below: 


status DoScene() 


{ 
BOOL done = FALSE; 


while(!done) 


{ 


UpdateTime() ; // Update simulation timers and frame count. 
GetControllers(); // Get game controller info. 
done = DoAI(); // Call each controller performing AI. 
if (!done) 
{ 
DoAnimation() ; // Position each instance node based 


// upon animation data in the template. 


PositionCamera(); // Update the current camera. 
DoRendering() ; // Render the scene. 
} 
} 
return statusCode; // No status processing in this example. 


Note that DoAI is basically implemented as follows: 


treeWalk (pControllerTree,callbackAI,NULL) ; // (See appendix A) 


Animation 


The animation system is a key-frame based playback system used to animate various attributes of a 
hierarchical skeleton-based model. In addition to traditional game animated qualities, light parameters 
and events may also be animated. 


Animation Data 
There are 4 categories of animation data supported. These categories are: 


> Geometry animation 


> Light attribute animation 
> Object attribute animation 
> 


Event spawning animation 
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Geometry animation 


Geometry animation is used to translate, rotate, and scale an object relative to the object’s local coordinate 
system (or pivot point animation). The method used is a stack-based system, where the first object in a 
hierarchy is brought into the world space coordinate system, then each object in the hierarchy is then 
brought into it’s parent’s (world modified) coordinate system in turn. 


The geometry animation does not actually effect the vertex information of the model. The result of the 
geometry animation is saved in each object’s “instance node” in matrix form. This allows the new world 
coordinate system matrix to be available for positioning of the object’s collision data during collision 
checking, for AI processing, and for supplying to the renderer along with the vertex information. 


Light attribute animation 


Light attribute animation is used to animate properties of a light in the scene. While the actual 
“geometry” of the light is not shown, lights may animate freely ina game scene. Note that if you wanted 
to show the “source” of the light, the artist is free to build an object that looks like a light, (such as a car 
headlight) and hierarchically attach a light object to the headlight. Also note that Geometry animation is 
available for lights as well. 


These animated values effect the attributes of the object’s instance, and is made available to the renderer. 
There are 3 types of lights supported in Mud, Sweat & Gears: 

>» Omni lights, which give light in all directions. 

» Directional lights, which give light in one direction as a plane (also called planer lights). 


>» Spot Lights, which cast light in a cone like a flashlight does. 


There are six light attributes that will be animated. The first four apply to all lights, while the last two 
will only apply to the spot lights. 


RGB color 


Red, green, and blue may be animated independently from 0.0 to 1.0. 


Intensity multiplier 


The intensity of the overall light may range from 0.0 (off) to any positive value. This effects the intensity 
of the light. This may be used not only to raise the light value, but may also be used to determine the 
brightness of lens glare and lens flare. 


Start attenuation 


As a light’s range to objects increases, the effect of the light diminishes if the start attenuation of the light 
is less than the range of the light. The intensity between the start attenuation and the range of the light 
will fall off by a TBD function. Likely falloff candidates are RMS (root mean square), logarithmic, or table 
driven. 


Range 

The range of the light is the range where the light stops having an effect on the scene. This is a sharp 
cutoff. If a more gradual cutoff is desired, setting the start attenuation value will allow the light to appear 
to dim until the end range is reached. 
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Umbra 


The umbra is a spotlight parameter only. Sometimes called the “hot spot”, the umbra is the brightest part 
(center) of a spotlight. The radius of the umbra may be animated. 


Penumbra 


The penumbra is a spotlight parameter only. The penumbra is the darker “outside” area of a spotlight. 
The radius of the penumbra may be animated, which will increase or decrease the radius that the light 
coverers. 


Object attribute animation 


Object attribute animation covers attributes that affect the look of the object in a non-geometric fashion. 
Currently, the only attribute that falls under this category is visibility. Once again, this attribute is done 
during the animation phase and is available not only for the renderer phase, but also during the AI phase, 
where it would be possible to have objects that are not seen by other AI objects... or objects that were 
hard to see (if such AI was required). 


Visibility refers to the translucence of the geometry of the object, where 0.0 visibility is completely 
invisible, and 1.0 is fully visible. This is used to fade objects in or out when appropriate, such as an 
explosion that is constructed out of a hemisphere, where scale will expand it, and as it gets near it’s 
maximum size animated visibility causes it to quickly fade away. 


Event spawning animation 


Events may be imbedded within an animation where the AI for the object under animation interprets on 
a case-by-case basis. Using the example of a tire with a nail in it, an animation could be used to spin the 
tire. When the animation got to the point where the tire would normally be in contact with the road, the 
artist could place a text event on the animation named “click”. The AI controller that is in control of this 
animation would receive a text event at the proper time in the animation, where it could then check if the 
tire was in contact with the ground and play the “click” sound. 


Adding sound events | 
Sound events are another form (although similar to the last example) of event spawning. In this the artist 
applies a sound event to the animation, such as a foot step noise in a run animation. Each time that the 
object's foot reaches the proper point in the animation a sound is played. This requires no further 
support by an AI programmer and is handled by the animation system. 
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Al 


AI for each object is handled in the AI phase of the game loop. The scene manager calls each registered 
object in turn, and the objects have an opportunity to do what ever action they deem appropriate. There 
are three types of object in the game that have complicated AI — cars, terrain, and camera. The camera is 
treated separately in the “Camera System” section. 


Car AI 


To first approximation, NPC drivers will attempt to follow a spline-based path around the track. There 
will be decision points embedded in the spline data that will enable the drivers to take alternate paths, if 
such exist and are “open.” NPC cars follow pretty much the same physics as the player cars, so the NPC 
driver must make decisions about how much gas, brakes or steering to apply to get the car to follow the 
splines around the track. 


To second-order approximation, the car AI will look for objects somewhat ahead or behind, and attempt 
to avoid or collide with them, as appropriate. Different NPC drivers will have different driving abilities, 
and will be more or less friendly toward the player depending on the NPC’s goals. 


Risks - Medium 
The risk in car Al is processing time. 


As currently envisioned, every NPC car will be interacting with the terrain at the same level as the 
player’s car. This means the full physics and collision model is active for each NPC car, that terrain data 
must be available to every NPC car, and that terrain deformation must be calculated for every car. That’s 
a lot of processing. 


We do not currently know how long this processing takes, and we may find that it is not feasible to run 
this full model for cars that are off-screen. If we find that the processing takes too long, we will drop 
down to either a simplified physics model or a statistics based determination of events off screen. 


Terrain & Deformation AI 


Terrain Al is what the terrain does in response to cars driving over or skidding across it, or to other 
events. Some percentage of the terrain is deformable, meaning that ruts will appear when cars drive over 
it. The physics engine will provide the terrain AI with information about how hard the tires are pressing 
into the ground, as well as the locations and size of the tires, and the terrain AI will decide whether to 
create ruts. Since we do not want cars to be able to create arbitrarily deep ruts as they cross the same 
terrain over and over again, we will maintain rut maps with information about how much the terrain has 
already been deformed. Past a certain deformation, ruts get no deeper. 


> Ruts themselves are implemented as displacement maps, and either the terrain engine or the 
rendering engine will be responsible for subdividing the polygons in existing landscape to create 
the ruts. 


>» Sandbars are a special case of rut-able terrain. Instead of being deformable to a certain depth 
from the original surface, sandbars are deformable to a set y height. This will allow trucks to 
nearly totally destroy sandbars as they splash through water. 


> Splashes in water are also part of the terrain Al. When a car drives through water, the terrain AI 
places a time-variant displacement map on the water (the big splash), and also calls to the particle 
system to create some water particles (the little splooshes). 
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In general, the terrain system will call to the particle system for particles when the physics system 
indicates that there is something skidding or sliding over the ground, and the terrain system determines 
that the terrain is of the correct type to create flying particles. 

Risks - Medium 

The risk in the terrain Al is in the number of additional polygons the displacement maps may create. 


At the moment, we do not know exactly how many polygons we can process, or how many polygons we 
need to make our scenes look good. In the current design there aren’t that many areas, but we may need 
to limit these still further. 


A further discussion of AI and our approach to implementation 


The AI for our game is broken down into a set of operations that are performed per time slice. Because 
the trucks in this game will be moving several inches per frame (at 60 fps), our time slices must be 
fractions of frames to avoid objects traveling through one another. 


Optimally we would like to update our truck AI 8-10 times per frame. Of course not every object needs 
to be updated that often and some objects don’t change at all. Luckily we have a system of controllers 
with priorities that allow us to decide how often each object AI should be updated. 


As described elsewhere, objects are categorized by whether they can be animated or changed in response 
to events. In this case we differentiate objects by whether or not they are controlled by a physics system. 


Whereas most objects will have a simplified control flow: 


Change to next animation state 

Move to new position based on animation path 

Check for collisions that have occurred from movement 

Generate events caused by collisions (such as change animation state or start a particle system) 


Move objects to resolve collision 


Oy SOU har 


Loop 


The control flow for a truck time slice is as follows: 
1. Get input 
2. Change animation based on input 


3. Move to anew position based on the animation path and/or velocity previously calculated by 
the physics system 


Check for collisions that have occurred from movement 
Calculate forces generated from collisions and latest input 
Generate events caused by collisions 

Move objects to resolve collision 


Update object velocity 


SOF C0 NO OL. 


Loop 
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Master or Slave 


The question becomes, which comes first — the AI or the physics? Which is in control? Does the physics 
system move the truck, maintain all the object structures that contain position, orientation and status, 
update the object matrix and basically resolve all collisions? Or is it up to the AI to do so, and accept 
only suggestions from the physics systems as to where objects should be moved, making the ultimate 
decision. 


Even within each approach here are multiple ways for the control to go. I’ve analyzed two of them here. 


Al is the master, physics is the slave 
In this scenario, each controller is processed in turn. 
The control flow for a truck time slice becomes as follows: 
1. Get input 
2. Step through each controller, getting each object instance 
3. For each controller, 
i) Al changes object’s animation based on input 


ii) AI moves object to new position based on animation path and/or velocity previously 
calculated by physics system 


iii) call physics system to check for collisions that have occurred from object’s movement 
iv) physics system calculates forces generated from collisions and latest input 


v) physics system sends messages to each object affected with collision event, and collision 
data: forces, velocity, orientaion, etc 


vi) Al checks message queue for current object to see result of collision. 


vii) if there is a collision, AI moves the object to resolve the collision using the physics data and 
updates any damage system or animation state, etc. The AI may choose to loop back to iii) a 
set number of times to make sure that where it is placing the object does not cause another 
set of collisions. 


viii) AI updates the object velocity based on physics data for next time slice 


4. Loop 


Imagine a worst case scenario. 4 objects are about to collide simultaneously. What happens? 


Controller 1: Object 1 moves into its new position. It’s all by itself. No collision. No problem. 
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Controller 2: Object 2 moves into its new position and collides with obect 1. The physics system 
calculates the forces and send the events and collision data to the message queues of object 1 and object 2. 
Object 2 immediately processes its collision data and moves safely out of the way. Object 1 waits to be 
processed next time around. 


Controller 3: Object 3 moves into its new position. Oops. It’s now occupying the same space as Object 2 
and its colliding with Object 1. Okay, no problem. Physics system calculates the forces and send the 
events and collision data to the message queues of objects 1, 2 and 3. Object 3 immediately processes its 
collision data and moves safely out of the way. Objects 1 and 2 patiently wait. 


Controller 4: Object 4 moves into its new position. Oops. It’s now occupying the same space as Object 2 
and its colliding with both Objects 1 and 3. We know the drill. Object 4 is moved and messages are 
waiting in the queues of objects 1, 2 and 3. 
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So let’s examine the message queue for each object as the collisions progress: 


MQ4 MQ3 MQ2 MQ1 
No collision Object 1 moves 
Collision Collision Object 2 moves 


Collisn resolved 
Collision Collision Collision Object 3 moves 
Collisn resolved 
Collision Collision Collision Collision Object 4 moves 


Collision resolved 


When it becomes time to resolve Object 1’s collision data, it will have compounded multiple forces that 
propel it way beyond its expected range. 


Physics is the master, AI is the slave. 


In this scenario, all objects are moved before collision detection occurs resulting in equal forces being 
generated as a result of multiple object collisions. 


The control flow for a truck time slice becomes as follows: 
1. Get input 
2. Step through each controller, getting each object instance 
3. For each controller, 
i) call Al to change object’s animation based on input 


ii) | physics system moves object to new position based on animation path and/or velocity 
previously calculated by physics system 


Step through each controller, getting each object instance 

For each controller, 

i) | physics system checks for collisions that have occurred from object’s movement 
ii) | physics system calculates forces generated from collisions and latest input 


iii) call AI for each object affected with collision event to change graphics, animation state, 
update damage system, etc 
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iv) physics system moves each object to resolve the collision using the calculated physics data. 
The physics system may choose to loop back to 4) a set number of times to make sure that 
where it is placing the object does not cause another set of collisions. 


v) physics system updates the object velocity for next time slice 


6. Loop 


The major drawback with this approach is almost immediately obvious—the controller hierarchy is 
traversed multiple times. 
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Renderer 


The renderer is divided into two pieces - a high level renderer and a low level renderer. Press Start is 
responsible for the high level renderer and for defining the interface to the low level renderer. Interplay 
is responsible for creating the low-level renderer. 


Each frame, the scene manager goes through the list of regions and decides which are visible, based upon 
the visibility list from the region that the camera(s) is(are) in. It takes the list of objects in these regions, 
does some additional high level visibility testing, and passes a list of visible objects down to the high level 
renderer. 


The high level renderer decides what LOD the objects should be displayed at, sorts the objects based 
upon priority and transparency, and, come rendering time, sends down a list of polygons to the low level 
renderer for displaying. 


The high level renderer also maintains knowledge of the low-level renderer’s state - lights, viewports, 
special PS2 effects, etc - and sends state change information to the low level renderer as necessary. 


The Scene Manager specifies which lights and cameras are in the scene, but it is left to the high level 
renderer to package up any state change information and send it to the low level renderer. 


The low level renderer is responsible for transforming, lighting, drawing and texturing the triangles. It is 
expected to be able to handle single triangles, triangle strips, triangle fans, points, and lines. It is expected 
to be able to handle transparency, translucency, backface culling, fog, multiple textures, texture blending 

functions (such as the PS2 supports), and reflections. 


Requirements for a Renderer 


Our scene description is a hierarchical list of all the objects in a game level organized by location or 
region. Each frame, the Scene Manager traverses this list handing off objects to the renderer to be 
displayed on the screen. 


Many factors affect how each object appears: 
> Time of day 

Weather 

Damage 

Mud 

Water 


VV V WV 


> Distance from the camera 


These can drastically change the physical appearance of the object, and the renderer must take into 
account each of these factors. 


Object Description 

Each object is broken down into each of its moveable or detachable parts. These subobjects can have their 
own texture, color, material properties (such as how reflective or mat the surface is) and can move 
independently. Typically the object will be decomposed into triangles, although we are looking into 
possible curved surface descriptions. 


A vertex or control point has the following information associated with it: coordinate data, x, y, z; vertex 
normal to indicate curvature, nx, ny, nz; texture data, u, v, per texture (there may be several textures). 
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The Conceptual 3D pipeline 


The conceptual 3D pipeline takes objects which have been defined in a local coordinate system called 
object space and assembles them into a scene or world space according to object matrices which specifies their 
position and orientation in the world. Subobjects are assembled into objects and objects into scenes each 
with their own set of matrices. 


Once the world has been assembled, lights, such as the sun, are placed in the world with a position and 
orientation. Lights, such as headlights, can also be attached to objects and can move with the object. 
Finally, cameras are placed in the world to determine how much of the world you'll actually be seeing 
and from what viewpoint. One you have chosen a camera, a viewing transform is applied to the objects to 
place them in the chosen camera space. The contribution of all light sources is calculated, texture is added, 
perspective is applied and shadows are projected. Object triangles are clipped to a viewing frustum, a 
truncated pyramid, and then projected onto a 2D plane. The remaining visible triangles are converted to 
screen space and clipped to either the screen boundaries or defined viewports which are subregions of the 
screen. 


Scene Manager traverses object hierarchy. 


matrix 
transform 


viewing 
transform : : 
object world camera clip screen | 


— | _ 
space space space a, space space 
oe 7 ‘ clipping & a 
i projection j 


* objects, cameras, 
and lights placed 


perspective 
transform 


screen transform 


viewport clipping 


Graphics Pipeline 


In reality many of these transformations can be combined. Typically the object, viewing and projection 
matrices are concatenated together into one matrix and vertex coordinates are transformed once. 


Lighting can be performed in object space by transforming the light vectors into object space or by 
transforming the normals into camera space. 


The GS only accelerates the final stage of the pipeline. Our renderer must be able to take objects in object 
space, process the entire pipeline before handing triangles off to the GS. 


Lights, Shadows and MultiPass Rendering 


There will be many types of light sources and lighting effects in Mud, Sweat and Gears. For dynamic 
lights, we will need to be able to change a light’s position and direction, turn it on and off, and set its 
physical characteristics such as the color of the light, its intensity, whether it’s a spot light, how wide an 
angle it covers, etc. 


Static light contribution will be precomputed ina light map. Light maps are low resolution textures that 
are indexed into like any other texture and combined with the results of previous lighting and texturing 
operations. This use of multiple textures implies multi-pass texturing through the GS, storing 
intermediate results, and applying the various combine modes with each subsequent pass. 


Shadows are dynamic and static according to their light source. Again, static shadows will be pre- 
computed and either stored as textures or as polygons and combined with previous operations. 


Dynamic shadows require more computation. A shadow map can be created by rendering the scene or 
portion of the scene from the point of view of the light source. Then the same scene is rendered from the 
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point of view of the camera (as it normally is). If an object is in front of the stored shadow map value, it is 
lit, if it’s behind, the object is in shadow. 


Reflection Vectors, Environment Mapping 


Reflections and particularly environment mapping enhances the realism of shiny objects. A reflection 
vector is computed that is normal to the surface and used as an index into a precomputed, coarse texture 
map. 


Transparency and Translucency Means Sorting 


Both textures and object material properties can have alpha values that are less than 1.0 indicating 
transparency or translucency. Because of the nature of Z-buffering, triangles that contain alpha values 
less than 1.0 must be rendered after all other triangles are rendered and then sorted so that they are 
rendered back to front. This must be done by the renderer, as the Scene Manager only knows about 
subobjects, and not about individual triangles. 


Levels of Detail (LODs), Bounding Calculations and Interpolation 


One way to reduce the amount of data rendered is to create levels of detail. Since objects far from the 
camera are smaller and appear less detailed, it is reasonable to portray them with less detail than when 
they are close to the camera. There are several approaches one can take to doing this. The most common 
way is through mipmapping, which reduces the level of detail in textures by storing prefiltered versions 
of the texture. Mipmapping is good for long walls into the distance which transition across many levels 
of detail. However, the number of triangles remains constant and some texture details which you’d want 
to be preserved are filtered away, such as lines for crosswalks or other distinguishing features. 


Geometry LODs can reduce the number of visible triangles for distant objects, but still preserve features. 
Mipmapping typically can not be used in geometry LODs because feature reduction is selective and 
vertices from one LOD to the next no longer match. 


Which LOD chosen is decided by either the distance from the camera or size of the object when its 
rendered on the screen. There is no point in rendering a 5000 or even 50 polygon object when it is only a 
few pixels on the screen. This presents a problem in our graphics pipeline described above. Distance from 
camera isn’t known until vertices are transformed into camera space and size isn’t known until the 
perspective transform is applied. It would be very time consuming to transform the vertex list of each 
LOD until the correct size or distance is found. Instead the scene manager will send the object bounding 
box or sphere down the pipeline, determine the correct LOD, and then send the correct object description. 


One of the issues of using LODs is the popping caused from substituting one level of detail for another. 
We plan to avoid this by interpolating the vertices from one LOD to the next using a simple blend 
function. 


car object 
LOD 1 LOD 2 LOD 3 
' ’ ’ 
body body body 
front back left front right front _left rear right rear 
bumper bumper wheel wheel wheel wheel 
Bae, Crores 

left right left right 
wheel wheel wheel wheel 


Subobjects within an object hierarchy. Note each level of detail of an object may have a different number of subobjects. 
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Progressive Meshes Reduce LOD Data 


Progressive meshes are a technique for reducing the amount of LOD data required using precalculated 
vertex splits to gain additional detail. All that is necessary is to store a coarse mesh and the sequence of 
splits. The renderer will need to traverse the split information adding vertices until the correct level of 
detail is achieved. 


The one drawback of progressive meshes is that it requires all the data be in memory at the same time. 
With discrete LODs, only the 2 transitioning LODs need be brought into memory. We will be using a 
combination of both techniques, most likely progressive meshes for the terrain and geometry LODs for 
the cars and other objects. 


Collisions Need to Be Computed in World Space 


Associated with each object will be a collision tree of bounding spheres or collections of bounding 
spheres. The collision tree may not necessarily reflect the same hierarchy as the hierarchy of the object 
parts. Whereas the object part division is determined by how the object will be rendered or animated or 
disassembled, the collision tree division is determined by AI events. 


Collisions must be computed in world space. This causes another break in our graphics pipeline. Most of 
the time a bounding sphere check will be sufficient. However, for those objects where precision is 
needed, such as the terrain and a car, individual triangles need to be checked. Therefore, an interim step 
of transformation to world space is needed. 


Z Problems and Solutions 


When 2 or more triangles have the same Z value, the order of rendering determines which one goes on 
top. If the order is not maintained from one frame to the next, flickering or sparkling occurs as part of the 
object disappears and then reappears. This also can occur because of precision errors from roundoff or 
truncation. 


Z values that are very close may resolve to the same value. In particular when rendering objects on a 
terrain, its very important that the objects appear in front of the terrain and not falling through. One way 
to get around this is to always render the terrain first. Another way is to introduce z-bias, which pushes 
an object forward a set amount. 


Some objects, like the sky, always need to be rendered first and some objects, like menus and overlays, 
always need to be rendered last. We will be using z priority to determine rendering order for these 
objects. Objects with a higher z priority will be rendered after objects with lower priority. 


Surface Deformations and Displacement Maps 


In Mud, Sweat and Gears, surface deformations, like ruts in the ground, waves in water, and mud 
troughs, will be created by displacement maps. A higher LOD mesh will be inserted around the collision 
area. Then each vertex of the mesh will be displaced according to 1 of 2 ways: 


>» For ruts, the displacement depth and length will be determined by the physics model. 


>» For mud and water, the displacements will be stored in a texture map. 


Indices into the displacement map will determine the height of the resulting vertex. 
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Shadows 


Shadows can be produced ina variety of ways. They come with different caveats. Render time and 
memory limitations will determine which shadow methods we choose. 


Traditionally, shadows are produced by attaching a transparent sprite to the bottom of an object causing 
the shadow to move with the object. The shadow is then blended with the ground, indicating how the 
object is associated with the ground. These attached shadows do not shadow any object other than the 
ground. And since the shadow is fixed, the effect is as if the light is either directly overhead or firmly 
attached to the object. 


To get a better approximation of shadows associated with the lighting of a scene, there is the concept of a 
projected shadow. These are typically done with projected textures. 


See: Segal, Korobkin, van Widenfelt, Foran, and Haeberli, "Fast Shadows and Lighting Effects Using Texture 
Mapping”, SIGGRAPH ‘92 for a more detailed description. 


Typically a texture is pre-generated that is the shape of the object that is casting the shadow. These 
textures need only be 1 bit, transparent bitmaps and can be a coarse approximation of the shape of the 
object. During the game, a texture matrix is created that takes the dot product of the plane of projection 
(such as the ground or a wall) and the direction of the light, and uses that matrix to basically warp the 
texture image onto that plane based on the distance of the light from the object. 


dotProduct = projplane[X] * lightdir[X] + projplane [Y] * lightdir[Y] + projplane [Z] * 


lightdir[Z] + projplane [W]; 
texMatrix[0][0] = dotProduct - lightpos [X] * projplane [X]; 
texMatrix[1][0] = - lightpos [X] * projplane [Y]; 
texMatrix[2][0] = - lightpos [X] * projplane [Z]; 
texMatrix[3][0] = - lightpos [X] * projplane [W]; 
texMatrix[0 - lightpos [Y] * projplane [X]; 
texMatrix[1] [ dot Product lightpos [Y] * projplane [Y]; 


1 
1 
texMatrix[2] [1 
1 


- lightpos [Y] * projplane [Z]; 
texMatrix[3 [Y 


- lightpos ] * projplane [W]; 


texMatrix[0] [2 
texMatrix[1] [2] 
texMatrix[2] [2] 
texMatrix[3] [2] 


- lightpos [Z] * projplane [X]; 
- lightpos [Z] * projplane [Y]; 
dotProduct - lightpos [Z] * projplane [Z]; 
- lightpos [Z] * projplane [W]; 


1 Gime | ae | | 


texMatrix[0][3] = - lightpos [W] * projplane [X]; 
texMatrix[1][3] = - lightpos [W] * projplane [Y]; 
texMatrix[2][3] = - lightpos [W] * projplane [Z]; 
texMatrix[3][3] = dotProduct - lightpos [W] * projplane [W]; 


Again, projected shadows do not typically shadow any object other than the plane of projection. To 
shadow other objects, you would need to create a new texture matrix for each object or polygon within 
that object by inserting a new projection plane into the equation. On the other hand, if you’re not overly 
concerned with exactness, you could use the same texture matrix for objects resting on the projection 
plane. The shadow could be grossly approximated by determining if the object was within the bounding 
area of the shadow and projecting the object’s texture vertices onto the plane. This approach works best 
with static lights and static shadows. When the object that is casting the shadow is moving, or the light is 
moving so that the shape of the shadow changes, there is a problem. What people typically do in this 
case is create the shadow on the fly using the stencil buffer using multiple-pass rendering. 


We are considering a modification of this algorithm recognizing that texture memory is limited. Instead 
of using a pre-computed texture, we could use a planar polygonalization of the image to create the 
shadow and the texture matrix to map the shadow to the projection plane. However, this method is, as of 
yet, untested. 
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Shadow volumes are used to shadow more objects than just the ground plane. In this scenario, a volume 
is created using the silhouette of the object as projected on the ground plane (using a similar technique to 
the above-described projected shadows), the direction of the light vector, and the object, itself. When 
another object intersects this volume, the portion of the object that is interior to the volume (using the dot 
product of the light direction and the polygon normal) is considered to be in shadow. The shadow can be 
“applied” by darkening those vertices, or the lighting calculations can be skipped for those vertices 
effectively resulting in a shadow. Although fairly accurate, this approach is computationally more 
expensive than the previous approaches. 


Diagram goes here.... 


For dynamic shadows, shadow maps provide more accuracy and the ability for soft shadows and shadow 
dropoff. The drawback is that this is another multi-pass rendering scheme and specific to a single light 
source. If you have multiple dynamic lights, you would need to create a shadow map for each light 
individually and then combine the results. In this scenario, objects within a scene are rendered first from 
the point of view of the light source. The z values are stored in a depth-map, or shadow map, which is 
treated like any other texture only it contains floating point values. Then the scene is rendered as it 
normally would from the point of view of the camera. The world coordinates of each polygon are 
transformed back into light coordinates and tested against the z-value stored in the shadow map. If the 
coordinate is behind the stored value, the object is in shadow. Otherwise the object is lit. The further 
back the object is from the light source, the softer the shadow. Obviously, this approach has the 
drawback of requiring more memory for each shadow map than the previous approaches and takes 
longer time to render due to multi-pass rendering. However, since we are only interested in the z 
information the first time through, it is a somewhat faster rendering stage —texturing, lighting, color 
blending is ignored. 


Fog and Clouds 

Fog and clouds will be precomputed, coarse textures of density information. To give the illusion of 
depth, there will be layers of textures for given distances. Determining the fog value is simply a trilinear 
interpolation of textures between 2 different layers. 


Reflections 

Reflections are handled by pre-defined environment maps. Reflective objects have a flag (“I’m 
reflective!”) and an associated environment map. The low level render is expected to be able to do the 
multi-pass rendering necessary to make the reflection work. The environment maps themselves are low 
resolution textures drawn by the artists, and are not created dynamically. 
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Making Water Look Alive 


Water moves in waves usually, so we will generate a function simulating waves to generate indices into 
the water displacement map. The new triangles generated from the displacements will also generate new 
normals to the surface. This will give us the appropriate reflections that you see in moving water. 


Water flooding into a canyon will be modeled by successive geometry LODs that have been prefitted to 
the canyon walls. As water is transparent, it will have a high z priority thereby being among those 
objects rendered last. We will not be modelling defraction of objects submerged in water. 


Risks - Medium 


There are few risks with the high level renderer. It is simply an interface with between the Scene 
Manager (and possibly other modules, if we find they need to call rendering functions directly) and the 
low level renderer. However, the low level renderer has its risks. 


The low level renderer will be written entirely in VU1 assembly, and will be very difficult to debug or 
change. Further, the number of polygons we can put in the game may be limited by the speed of the high 
level renderer. Since we do not yet have a PlayStation 2, and have not yet gotten a feel for where the 
bottlenecks in our renderer are, we may end up making the wrong speed trade offs in the low level 
renderer. These may be difficult to correct later on. 
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Camera System 


Providing a method of decoupling the camera has been a classic problem for 3D games since the 
beginning. Many games use a direct method that can give you a headache (like DOOM-64) or they put 
the vehicle on a Popsicle stick, like a lot of Indy and Formula-1 racing games we've all seen. It gives you 
the feeling that the vehicle isn’t attached to the road, but rather to the screen — and for good reason, it is. 


This Camera System decouples the active camera from the action by two degrees, solving the traditional 
Popsicle problem (and others as well). 


It allows you to set a target for the camera to track (internally called the Track Target), by setting and 
managing four values: 


» The track target x, y, z (target object’s position) updated each frame (if the target is moving). 
> The distance to keep from the target object. 

» The locale (or angle) about the target object on the X/Z plane. 

> 


The altitude to seek relative to the target object. 


The active camera seeks its Surveillance Point using the D-O algorithm. 


The code facilitates multiple cameras and could be easily extended to have cameras automatically follow 
Splined paths while switching which camera is active. An engineer could, for instance, put several 
cameras into motion about an object and randomly switch between active cameras. 


The Surveillance Point (or SP) is key in the success of this system, because it is where the camera is 
seeking to be. The SP in turn, seeks it’s place relative to the Track Target (or target object). Both use the 
same method, the simple D-O: (destination — origin) / aggression 


Depending on the aggressiveness of the camera object, it will move more or less quickly to its target 
location. This type of camera is ideal for following moving objects, since its motions will complement the 
motions of the objects themselves. There are two types of aggression: 


> Pursuit Aggression — internally referred to as just “aggression.” It manages how quickly the 
camera reaches its Surveillance Point (SP). This is set using the function SetAggressive(x). 


> Locale Aggression — manages the aggressiveness of the Surveillance Point reaching its Locale 
(angle) about the track target on the X/Z plane. This is set using SetLocaleAggressive(x). 


Setting Locale about an object will short circuit - meaning that if you set it to 10 degrees, and then set it to 
350 degrees, it will pass through zero to get there instead of making the longer (and senseless) journey. 


Managing the Camera System is very easy with the primary controls, however there are times when you 
might want to bypass the primary operational method. In this circumstance, one might be tempted to 
manage the Camera directly. Moving the camera directly is a bad idea — so in the spirit of decoupling 
our camera from the target object, an alternate service is provided: 


Once set into the alternate pursuit mode, you manage tracking of the target by using SetViewReference() 
and manage the camera’s position by using SetSurveillancePoint(). 


Risks - Low 


The code already exists and has been used in other games. The only real issue is that the code as written 
does not deal with objects occluding the view of the target object. A higher level AI must be written to 
recognize this case and either move the camera or turn off the visibility of the offending object. 
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Specification 


Definitions: 


View Point (also known as VP) 


Where you are... the camera's current position. 


View Reference (also known as VR) 


What you are looking at, or tracking. 


Surveillance Point (also known as SP) 


The point where you want the camera to go, the SP maintains it's position relative to the target. 


Locale 


An angle about your target in degrees, the locale operates in the XZ plane. 


Aggression Level (Pursuit Aggression, Locale Aggression) 
Defines how we pursue the target, ranges LAZY to STAPLED-ON 


Track Altitude 


How high (or low) we put the camera relative to the target. 


Track Distance 


How far we must stay away from the target on the X/Z plane. 


General CS Functions: 


InitCamera(*camera, distance, delta_height, locale_angle, tx, ty, tz) 


This function creates your camera position by knowing the target object’s position (tx, ty, tz) and your 
angle in relation to it (locale angle). To do a "fly-in," use this function and then force the camera to a 
temporary position using PutCamera(). Setting the angle here will snap to that Locale, but don’t use this 
function for that, use ResetLocale() instead. 


Parameters required for this function (in order) are: 
> Pointer to an instance of aCAMERA object 
Distance camera should keep from target 
Height of camera above target (relative height, could be positive or negative) 


Locale angle about target (in degrees) 


VV V WV 


Target coordinates x, y, z 
Passing a NULL pointer to this function in lieu of a CAMERA object will result in using the default 


camera. Each time a CAMERA object is initialized with this function is becomes the current camera as 
well. To specifically choose a camera, use the function SetWhichCamera(*camera); 


SetTrackTarget(x, y, z) 


Tell the camera system where to look — If your Target is moving, make successive calls to this function. 
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UpdateCamera() 


This is the camera tracking update function. It should be registered with the Scene Manager or V-Blank 
Interrupt to be called once per frame — this guarantees frame-rate independent camera motion. There are 
two operative modes used in the normal operation of the Camera System. They are controlled by using 
the SetCameraMode() function: 


SetCameraMode (IDLE) ; 
or SetCameraMode(PURSUIT_MODE); (default) 


PutCamera(vpx, vpy, vpz 
This function forces the actual position of the current camera to the specified coordinates, it is a 
temporary setting because the primary behavior of the Camera System is to seek the Surveillance Point. 


The camera will smoothly relocate from its current location to the Surveillance Point as UpdateCamera() 
is called (unless SetCameraLock(ON) is invoked). The Surveillance Point is set initially in InitCamera() and 
is updated in real-time while the target is moving (every frame UpdateCamera() is run). 


SetLocale(angle_degrees) 


Rotates Surveillance Point about the track target. This is the primary means of controlling where the 
camera is located on the X/Z plane about the Target. Update this value to quickly swing the camera from 
the front of the car to the back, or the sides (presuming of course, that you are using the vehicle as the target 
object). It could also provide an interesting visual for sliding around corners if one were to link the car 
physics to this value. 


GetLocale() 


Returns the Locale setting for the current camera. This is the actual locale setting, not where it’s 
intending to go. See GetLocaleDest() to learn where the camera is currently trying to go. 


GetLocaleDest() 


Returns destination angle for Locale of the current camera (not it's current Locale). 


ResetLocale(angle, locale_aggression) 


Snaps to a Surveillance Point about the current Track Target. Locale aggression levels are 0-8, refer to the 
SetLocaleAgegressive(x) function for more information. 


SetTrackAltitude(delta_height) 


Sets the camera tracking altitude above tracked object for the current camera. User specified, no default. 


GetTrackAltitude() 


Returns the tracking altitude of the current camera. 


SetAggressive(value) (Pursuit Aggression) 


Sets the pursuit aggression value for the current camera. The “aggressive” is set in the range of 0 and 6, 
with zero being disgustingly aggressive. This is what other primitive camera systems would use, giving 
you the impression that the vehicle is on a Popsicle stick; might as well not use the Camera System then. 


A value of 2 or 3 is a normal value for this type of aggression. A value of 6 is very slow in catching up. 


Can be set in the range of 0-6; 0=most aggressive, 6=least. Default is 3. 
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GetAggressive() 


Retrieves the current camera’s pursuit aggression value. 


SetLocaleAggressive(locale_aggression) (Rotation Aggression) 


Sets the Locale aggression value for the current camera. The “aggressive” is set in the range of 0 and 8, 
with 0 being the equivalent of NO tracking at all. Basically it puts the camera at the Locale immediately. 
Using a value of 2, 3, or 4 is normal for most operations. Eight is the going to make it crawl like a snail. 


Locale aggression levels are 0-8: 0=stapled on, 8=slow rotation. Default is 3. 


SetTrackDistance(distance) 


Sets the distance of camera from the tracked object. User specified, no default. 


GetTrackDistance() 


Returns the tracking distance for the current camera. 


SetSourceOverride(ON | OFF) 


This command is not technically part of the Camera System, as it simply sets a flag that the game engine 
uses. It's purpose is to ignore settings from the AI; we leave it up to the AI to pay attention to this flag. 


For instance, you would use this if you wished to temporarily take control away from the normal AI and 
say... perform an Instant Replay or cinematic sequence — or some other purpose. The function is benign 
as it only sets a value in the active camera’s structure. Default is OFF. 


GetSourceOverride() 


Returns the state of the Source Override flag in the current camera’s structure. 


GetCameraStatus() 


This function returns the activity status of the “current” camera: 
> CAMERA STOPPED is returned if the destination has been reached. 
> CAMERA_ ACTIVE if not. 

SetCameraMode(IDLE | PURSUIT MODE) 


This function controls the two operative modes of the Camera System: 
> IDLE is used to halt all camera pursuit activities. 


> PURSUIT_MODE is used as the normal and default camera operation. 
GetCameraMode() 


Returns the value of the current camera mode. See above for details. 


SetWhichCamera(*thisCamera) 


Passing this function a pointer toa CAMERA object will make that camera the current camera. All 
subsequent camera operations will affect this camera only. Leaving all other cameras completely alone 
and utterly helpless. 
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Offset Functions 


These functions are useful to the extent that they can be used to temporarily manipulate the current 
camera by adding to the value of an existing variable. 


SetLocaleOffset(angle) 


Same as SetLocale() but applies an offset to that existing value. This value is ZERO by default. 


GetLocaleOffset() 


Returns the offset value for Locale being applied to the current camera (if any). 


SetDistanceOffset(distance) 


Same as SetTrackDistance() but applies an offset to that existing value. This value is ZERO by default. 


GetDistanceOffset() 


Returns the offset value for TrackDistance being applied to the current camera (if any). 


SetAltitudeOffset(relative_altitude) 


Same as SetTrackAltitude() but applies an offset to that existing value. This value is ZERO by default. 


GetAltitudeOffset() 


Returns the offset value for TrackAltitude being applied to the current camera (if any). 


SetTrackTargetOffset(x, y, z) 


Applies an offset to the track target position. This value is ZERO by default. 


ResetOffsets() 


Resets all of the above offsets to ZERO. 


Locking Functions 


These functions are (or will be) used extensively to temporarily lock aspects of the Camera System so they 
will not affect the view in their normal way. 


For instance, you can apply a lock to the camera itself using the function SetCameraLock(ON) and until 
you unlock it, the camera will sit obediently in its current location. Meanwhile all other aspects of the 
Camera System will function oblivious to the camera’s dilemma. Tracking of objects will continue, but 
now your camera acts as if its on a tri-pod. It can look — but it can’t touch. 


SetCameraLock(ON | OFF) 


Prevents the Camera from moving from its location when set to ON. Default is OFF. 


GetCameraLock() 


Returns the state of the Camera Lock for the current camera. 


SetTargetLock(ON | OFF) 


Prevents the View Reference from being updated. Default is OFF. 
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GetTargetLock() 


Returns the state of the Target Lock for the current camera. 


SetLocaleLock(ON | OFF) 
Prevents the Locale being updated. Default is OFF. 


GetLocaleLock() 


Returns the state of the Locale Lock for the current camera. 


Miscellaneous Functions 


These functions are not extensively used, but occasionally have been needed. 


SetLocaleVelocity(velocity) 


This function sets a constant locale velocity (should normally be zero). This value is ZERO by default. 


AddLocaleVelocity(velocity) 


Same as SetLocaleVelocity, but only a one-shot application used the next time UpdateCamera() is called. 


GetLocaleVelocity() 


Returns the current velocity applied to the current camera. 


GetAverageVelocity() 


Calculates and returns the velocity of the camera. The current implementation uses a distance 
approximation (max + 3/8 min), which historically has been quicker than square root of the sum of the 
squares for magnitude. This is probably a moot point on the PS2, but we shall see. 


GetTrackTarget(*x, *y, *z) 
Returns the coordinates of the track object. 


* 


GetCamera(*x, *y, *z 


Returns the coordinates of the camera. 


StartShakeCamera() 


Starts a camera shake, used for impacts and bumps to show the effect of the camera getting pounded. 


Secondary Control Functions 


Necessary tools for the alternate control method of the Camera System. 


SetViewReference(x, y, z 


Access the decoupled point for target object, View Reference. 


SetSurveillancePoint(x, y, z) 


Access the decoupled point for the camera object, Surveillance Point. 
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Physics & Collision 


Brief Overview 


Physics System 


The physics system is a 10+ degrees of freedom, rigid body system. Cars are modeled as single rigid 
bodies with wheel masses attached by springs, with additional springs providing roll support (this is 
additional support comes from a “sway bar” in actual cars). Cars will follow the laws of physics in their 
motion, interaction with the road, and collisions with other objects. Different road surfaces and different 
tires will have different coefficients of friction, which will effect the car’s handling. We will also model 
differential power output from the engine to the wheels (a standard feature on 4WD cars), allowing us to 
further fine-tune the handling of the cars. 


Risks - Medium 


In order to interact with the environment correctly, the physics engine must be run at significantly greater 
than 60 fps. Assuming that a car’s maximum speed is 120mph, we need to be able to run the physics 
engine at about 6 times per frame if we want to be able to resolve objects that are six inches wide. The 
physics engine is complicated, and this may involve a significant amount of processing. Further, if we 
need to run the full physics engine for each of the NPC cars (see Car AI section), the amount of 
processing required goes up by a factor of ten. We will probably end up running the physics on VUO, but 
whether the VU0 can handle the load, and whether this off loads enough processing from the CPU 
remains to be seen. If needed, we will drop down to a more basic physics model (incorporating many 
fudge factors for frictional forces) or run the physics engine at a slower rate. 


There are also currently issues involved in calculating the frictional forces, but those should be resolved 
as the physics engine is built. 


Collision Detection 


Initial culling for collision detection will be based upon gems. Since gems are disjoint (although of course 
a parent completely contains its children), an object that is in gem A but not in gem B will not collide with 
an object that is in gem B. 


Individual objects will have collision hierarchies of either bounding spheres or bounding boxes. Different 
objects can use different collision geometry, as appropriate. Objects will have a flag to tell the collision 
detection module whether to base collision decision solely on bounding geometry, or to proceed down to 
the polygon level. 


Collision detection for cars will be run at 6-8 times per frame, enabling us to resolve objects 6” wide when 
the car is moving at 120 mph. Collision detection for other, slower moving objects, will happen less often. 
This should be good enough to keep objects from going through one another, or significantly 
interpenetrating. 


Risks —Low 


There are two issues — (1) will the collision detection system run fast enough, and (2) will it be accurate 
enough. There always ends up being a trade off between the two. Accuracy comes from polygon- 
polygon intersections run extremely often, and speed comes from simple bounding box calculations, 
done occasionally. Since we can control both the rate of collision detection and the type of collision 
detection (polygon or box), we should have adequate control to make the trade offs correctly. 


11/3/99 * PRESS START CONFIDENTIAL *** Page 33 of 65 


Technical Design Document 
Mud, Sweat & Gears: Off-road Madness Press Start, Inc. 


Vehicle model 


At the most basic level, the car is modeled as a single rigid body with four smaller rigid bodies (a.k.a. 
“wheels”) attached to it via damped springs (a.k.a. “suspension”). 


Although we may decide to have other moving bodies attached hierarchically to the car (for example, 
headlights that rotate up, or an antenna that sticks out the back), they will not affect the physics model. 


fig 1 - basic physics model 


The car is given the standard six degrees of freedom - translation in x, y, and z, and rotation about the 
three axis. The wheels are allowed to rotate more or less independently, so each wheel has a separate 
rotational velocity . In addition, the front wheels pivot from side to side (“steering”) and all the wheels 
move up and down in response to bumps in the road. All together this is 6+4+1+4 = 15 degrees of 
freedom, although the angular velocities of the individual wheels are somewhat coupled. 


With regard to the competition — we have seen racing games that claim to use the angular momentum 
generated by the turning engine as a separate degree of freedom. To our knowledge, the only thing in a 
gasoline engine with much angular momentum is the fan, and we don’t believe that is massive enough to 
contribute significantly to the angular momentum of the car. However, we are not an experts on engines, 
and anyone who knows better is welcome to enlighten us. 


Engine vibration 


It has been pointed out that the car should vibrate as the engine is revved. That's fine, but the vibration 
should not be part of the physics model per se. For the most part, the vibration is cosmetic — it doesn’t 
really affect how the car steers, or how it flies through the air, or how it hits bumps in the road. 


What effect the vibration does have is much smaller than the physical effects we are trying to model here. 
That doesn’t mean that the car can’t vibrate — it’s easy enough to add a small offset to the position of the 
body at each frame. It just means that the vibration isn’t part of the physics. 


Suspension system 
There are three main factors that influence the suspension: 
» The spring constant 
» The damping constant 
> The maximum length of travel (both up and down) of the wheel. 


If the wheel is at its maximum travel, additional forces in the max’d direction will be transmitted directly 
to the car body. For the first pass, we plan to make the spring constant, well... constant. However, in 
real life the springs are often made so that the spring constant increases as the spring is compressed, 
resulting in better handling. Depending on time and performance issues, we may wish to make this adjustment. 


Unless someone can give a good reason for doing otherwise, the suspension system parameters — spring 
constant, damping constant, etc — will be the same for each wheel. 
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Body Sway 


Related to the suspension system is a bit of hardware called the sway bar. The sway bar reduces body 
sway (which is produced by inertia when going around a turn) by adding a spring that counteracts the 
lateral differential compression of the suspension system. 


In English, that means if the car heels over to the right, the sway bar pushes it back left. A good sway bar 
is essential to the handling of a vehicle with a high center of gravity. 


Tires and Road Friction 
There are three different kinds of friction associated with the road surface: 


>» Static friction 
> Sliding friction 
> Rotating friction 


Static friction is the friction you need to overcome to get something to start sliding. Sliding friction is the 
friction associated with objects slipping over the ground, and rotating friction is the friction associated 
with rolling objects. 


In general, F(static) > F(sliding) > F(rotating). We can model a variety of different tires and road surfaces 
by creating a simple lookup table with these values. 


A final column in the lookup table would be used for all “non-tire” objects — like the car itself sliding 
along the road. 


In real life, thin, wide tires deform less when going around a turn, giving the car better traction. In the 
game approximation, I’m not quite crazy enough to try to model this effect directly. We’ll probably 
ignore this factor for the first revision of the physics engine, but depending upon time and performance 
issues, we may want to add it in later. I would suggest modeling it as a “tire performance coefficient”, 
between 0 and 1, which would be weighted by the radial acceleration. You’d multiply this coefficient and 
the normal static friction of the tire/road combination together to get a new coefficient of static friction, 
which would in turn determine whether the wheel lost traction with the ground. 


fig 2 - side, thin tire vs narrow, thick tire 


Flat Tires 


Generally, if a tire goes flat and you insist upon driving on it, the rims cut the wheel to bits and you end 
up riding on steel. Without a tire, the wheel’s effective radius is reduced, you lose a lot of traction with 
the road, and you probably start doing serious damage to the car itself. 


Oversteer and understeer 


Oversteer occurs when the car turns quickly and the back end swings out further than expected, causing 
the car to turn faster than expected (albeit with somewhat less control). 


Understeer occurs when the front end swings out, causing the car to turn less quickly than expected. 
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Both these effects can be modeled by inertial “forces”, and depend upon the weight distribution of the 
car. If the static friction of the road with the tires in the back of the car is not great enough to move the 
back end of the car without slipping, oversteer occurs. If the static friction of the road with the tires of the 
front of the car is not great enough, oversteer occurs. 


fig 3 - Oversteer (a) and understeer (b) 


Engine Power and Differential Traction 


The power that can be provided by an engine varies depending on the RPM of the engine. Every engine 
has its own Power versus RPM curve. For this game, we’ll probably model that curve with a few points, 
and interpolate between them when necessary. 


The power that the engine puts out is used by the wheels; causing the car to move faster, jump higher, 
whatever. However, the power available to each wheel is not necessarily constant, and is also not 
necessarily the same as the other wheels. This fact is extremely important in off-road racing, where 
different wheels may be subject to very different forces. 


In real life, there are a couple of ways of applying different amounts of power to different wheels: 
» Cutting power to wheels that are slipping while increasing power to the wheels that are gripping. 
» Applying brakes to slipping wheels. 


We can do either in our game. The effectiveness of this system (part of the car’s “handling”) will be 
reflected in how quickly the power loads can be rebalanced. 


Collision detection 

In discussing collision detection, we are going to differentiate between: 
>» Collisions between ordinary objects. 
> Collisions between the tires and the terrain. 


Collisions between ordinary objects are relatively rare, and will be calculated in the standard way — using 
bounding boxes or spheres first, finally proceeding to intersections between individual polygons. 


Collisions between the tires and the terrain happen all the time. It’s called driving. To help simplify 
things a little bit, we model the wheels as cylinders of some given radius and width, and intersect that 
cylinder with the polygons of the road. 


>» We first cull the possible candidates for collision by comparing their footprint with the footprint 
of the wheel. 


> Then we check to see if the plane of the polygon is within the radius of the center of the wheel. 
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>» Finally, we do the full intersection with any remaining polygons, figure out if any serious 
collisions have occurred (penetration greater than some €) and adjust the suspension system 
accordingly. 


Collision deltas, or Yes, We Really Do Have to Check That Often 


One of the more difficult problems in collision detection is noticing when one object has passed through 
another object. At the first time slice the object is in front of the other object, and at the second timeslice 
it’s behind. At neither time do the two objects collide, yet, something happened in the middle. 


There are several methods for handling this problem: 


> The first is brute force - we make the At’s small enough that, compared to the size of the 
objects that are colliding, we don’t miss the collisions very often. 


>» The second is predictive paths — we figure out where the object(s) would be if they didn’t 
collide, and then extend bounding boxes around the entire path of the object. If the extended 
bounding boxes collide, we increase the time resolution to figure out exactly when and where 
the collision occurred. This method works best when colliding individual objects with 
individual bounding boxes. 


WV 


The third method is front/back differencing — first object was in front of the other object 
initially, but behind after the time step, a collision probably occurred. This method works best 
with collisions with static surfaces (like walls), or with collisions with objects that are much 
faster than the surrounding objects (like bullets). 


The trouble with the second and third method for this type of game is that they’re optimized for the non- 
colliding case. Most of the time the bounding boxes won’t collide (or at least, there’ll be only one collision 
within the time slice). Also, most of the time, the object won’t have gone through the wall and we won’t 
have to figure out exactly when and where. 


Unfortunately, ina driving game over rough terrain, we’re colliding with things on the ground all most 
all the time. Worse, the lack of a collision also has physical effects! The car doesn’t just sail smoothly 
over a pothole. It drops down due to gravity, and possibly slams into the far rim of the hole. Neither the 
second nor the third method can account for this. 


So we're back to brute force, at least for moving the car over the ground. Now the question becomes, 
“How often do we have to check?” The answer to that question really depends on the resolution you 
want when interacting with ground objects. 


If you want the car to react fairly naturally to a pothole that is 2 feet wide, you want to check at intervals 
of significantly less than 2 feet. The exact timing depends upon the speed of the car. 


Doing some quick calculations, maximum car speed = 120mph = 3 ft / (1/60sec), and if we want our 
resolution to be about 5 inches (not unreasonable) that’s 8 times per frame. Clearly if the car is going 
slower we don’t have to run the physics model and check for collisions as often, but that’s about the 
upper limit. This values are again different with the addition of nitro. 


Bumpers 


Bumpers will not be part of the physical model. Collisions with the bumpers will be reported back to a 
damage assessment model (as will all collisions except collisions between terrain and tires). It is the 
responsibility of the damage assessment module to determine whether the bumpers can absorb the 
collision without damage, or whether there is harm done to the car. 
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Rollover and the problem of self-righting 


In the interest of game play, cars should never get stuck upside down. (For some reason, players find 
“cockroach emulation mode” annoying.) Clearly, in the real world with real physics, cars do occasionally 
land on their backs. There are several possible schemes to get cars back on their wheels. I’m not stuck on 
any of them yet, and would welcome further suggestions. The fourth suggestion, “Hand of God” will 
probably be implemented as a fall back when all else fails. 


> Bug wiggle. This is actually used in an existing game, Rally Cross. The top left and right 
controller buttons wiggle the prostrate car back and forth. Eventually it gathers enough 
momentum and flips over. 


>» Invisible rubber band. A “righting force” is applied to help push the car over. This is a bit 
more difficult than the option above, and may cause some motion artifacts at other times. 


>» Predictive push. When we detect that the car is flipping over, we make a guess as to where and 
how it’s going to come to a stop. If the final position isn’t to our liking, we add an additional 
little push or pull. 


> Hand of God. The car is on its back. The angels sing. The car flips over. 


Factors that aren’t in the model 


Because even next generation systems are never powerful enough, many effects that influence the motion 
of the car have been left out of the physics model. Here we list as many of them as we can think of, so 
that we really understand not just what we are modeling but what we aren’t, and so that anybody who 
feels strongly that they should be included can get in a few cents worth. 


These things have been left out: 


> Effect of wide-thin tires on traction. As mentioned in the tire section, wide-thin tires hold their 
shape better on turns, resulting in better handling. 


>» Tire pressure. This effect is similar to the wide-thin tires effect. Under inflated tires deform 
under pressure, resulting in poor handling. 


> Torsion bars/Frame twisting. Torsion bars are put between the struts of the vehicle, and resist 
the twisting of the frame. Since the model of the vehicle frame is entirely rigid, we don’t need 
torsion bars. 


» Wind. Although we'll add a frictional force proportional to the speed of the vehicle (i.e., wind 
resistance), we are not planning to model the wind itself. Nope, your top-heavy Toyota will not 
get blown over by a gust coming off the desert. 


>» Effect of changes to the car’s geometry. As stated at the beginning, we are not going to change 
the mass, the center of gravity, or the inertia tensor because something inside the car moved, or 
because a fender fell off. 


» Springiness/sponginess of the ground. The ground may provide more or less friction, but it is 
always pretty hard. What about mud? 


Performance Analysis 


The physics model for the cars in the game isn’t overly simple. In fact, it’s about as complex as the 
models used in the current generation of high-end PC racing games. Given that the game is supposed to 
be more of an arcade game than a simulation, one might ask if we need a physics model that is this 
complex. To that question, we would answer YES, for a number of reasons: 


> Because it will be expected. As the processing power available goes up, the expectations of the 
players go up. Already, one of the main complaints people have about racing and driving games 
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is that the physics doesn’t feel good enough. People didn’t complain about physics back in the 
Sega Genesis days. Going forward, the complaints are just going to get worse. 


-  » Because it’s an off-road racing game! This game is all about bumping over things, getting air 
and bottoming out the suspension. You can’t do that in a convincing manner without paying a 
lot of attention to the physics of the model and the interactions between the model and the road. 
Maybe you can get away with a simpler model in a game like Driver, but you can’t here. 


Given that we want a good physics model, the next question is: “Can we afford it?” Now, consider. 
Physics models with this degree of complexity are already being run on today’s PCs. They do it. Yes, the 
physics sections will show up on the performance analysis charts. But no, it shouldn’t prevent the game 
from being fun. We are considering off-loading a lot of the physics calculations to the VUO, running in 
independent mode. It seems like an ideal thing for that processor to do. 


However, here are couple of suggestions on how to reduce the processing power needed by the physics 
engine, if we find it necessary: 


> Notall cars are created equal. Cars that cannot be seen by the player don’t have to follow the 
same laws of physics. This is the “If a car hits a tree in a forest and no one hears it, do I really 
care?” dilemma. We can use much simpler statistical methods to determine the paths taken by 
offscreen cars, and the damage inflicted upon them and by them. 


> Reduction of complexity. If necessary, we can model such effects as oversteer and understeer, 
wheel spin and skid in look up tables instead of calculating forces. If necessary, we can eliminate 
differential wheel power, and the effect of the angular momentum of the car’s wheels on the 
torques experienced by the car itself. We can also reduce complexity dynamically as required. 


In the text of this document, I’ve also included a couple of suggestions on ways to make the physics 
model slightly more complex, should we decide we can spare the extra cycles. 


Some math 


The actual physics in this model is derived from standard Newtonian mechanics: F=ma = dp/dt, 
T=Ia=dL/dt, momentum conserved otherwise. 


Forces come from several different places: 
>» The engine, acting upon the wheels. 

The brakes, acting upon the wheels. 

Collisions with objects or the road. 


The springs, acting upon the wheels and the body. 


V VV WV 


Wind resistance, acting upon the body and proportional to its velocity. 
> Our friend, gravity. 


We intend to use Euler’s method to approximate the results of the differential equations. This method is 
quick and easy, although not very accurate. However, this is a game not an engineering simulation, and 
we believe that the inaccuracies caused by the solution method will not be visible to the player. 


Euler’s method also suffers somewhat from instability — if the springs used in the simulation are “stiff” 
with respect to the time steps used to evaluate the differential equations, huge internal forces can be 
generated that cause the model to behave in all sorts of undesirable ways. To avoid this problem, we 
shall be keeping the springs in the model to a minimum, and are planning to use impulsive forces rather 
than stiff springs to model collisions. 


Although stiff springs probably produce a better model, we’d like to make sure that a) We can run the 
simulation and play the game at the same time, and b) Cars don’t suddenly start leaping tall buildings at 
a single bound. 
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Pertinent Structures 


Press Start, Inc. 


The physical model of a car consists of a rigid body (the car body), which is tied via springs to four 
wheels. The springs on the wheels are constrained to move only up and down, as seen in car body 


coordinates. 


Structure holding initial dimensions of the vehicle 


typedef struct physCarDim { 


int bodyW, bodyL, bodyH; 
int cabW, cabL, cabH; 
int engW, engL, engH; 
int dtrW, dtrL, dtrH; 
int bodyOSx, bodyOSy, bodyOSz; 
int cabOSx, cabOSy, cabOSz; 
int engOSx, engOSy, engOSz; 
int dtrOSx, dtrOSy, dtrOSz; 
int bodyM, cabM, engM, dtrM; 
int axleR, axleF; 
int wheelR, wheelW, wheelM; 
float gear[6]; 
float differential; 
int powerCurve[9]; 
int torqueCurve[9]; 

} physCarDim; 


Body width, length, and height. 

Cab offset, width, length, and height. 
Engine offset, width, length, and height. 
Drive-train offset, width, length, and height. 
Offset of body from origin. 

Offset of cab from origin. 

Offset of engine from origin. 

Offset of divetrain from origin. 

Mass of above. 

Positions of the axle. 

Wheel info. 

Gear ratios. 

Differential ratio. 

Power in hp, at x1000 rpm 

Torque in ft-lbs, at x1000 rpm 


Structure holding physics properties of the vehicle 


typedef struct physCar { 
ps4Matrix lwMatrix; 
ps4Matrix = wlMatrix; 
ps3Matrix bodyPMI; 
ps2Tensor inertia; 
ps3Vector velocity; 


float posX, posY, posZ; Car position in the world, measured from center of mass. 
float roll, pitch, yaw; Car angular coordinates, in human understandable terms! see also lwMatrix 
ps3Vector angVelocity; Car angular velocity around center of mass. 
float cmx, cmy, cmz; Center of mass, in car coordinates. 
float width; Width of car collision geometry — when do we get the rest of the car? 
int mass; Mass of car 
int gear; Gear car is currently in. 
int tireM; Mass of tire of car. 
int tireX; x value on side of car where tires grow XXX need something else here! 
float axlePosZ[2]; Neutral position of the tires, Z axis 
ps3Vector _ tirePos[4]; Position of the four tires 
float tireOmega[4]; Angular velocity (around the axle) of the four tires. 
int axleF, axleR; Position of the axles. 
physCarDim dim; Car's physics dimensions. 
float tireR, tireW; Wheel/tire dimensions. 
msgTire tireType; Type of tire — referencing enumeration. 
float tireAngle; Angle that the front tires are moved through. 
float axleZ; Neutral position of the axle of the wheels. 
float tireFRvel, tireRRvel, tireFLvel, tireRLvel; Velocity of the tires to or from the body of the car. 
float shockK, shockD; Shock absorbers, spring constant and damping factor. 
float shockMaxxX; Maximum amount of travel. 
float brake, gas; Amount of gas and brake applied, 0 -> 1 (is this really part of the car?) 
float maxBrake, maxGas; Maximum amount of force that the brakes and the engine can generate. 
float gearRatio[6]; Gear ratios. 
float differential; Differential ratio. 
float torqueCurve[9]; Torque in ft-lbs, at x1000 rpm 
} physCar; 
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What's left out 


Sway bar, differential engine power, engine power curve, flat tires, rpm, flags to tell whether the car is 
skidding, has wheels off the ground. 


Networking 


Networking will be implemented by building a socket-style interface on top of whatever networking 
protocols Sony gives us. Both connected (TCP) and connectionless (UDP) types of sockets will be 
supported. 


Risks - High 

Networking on the PS2 is a great unknown. We don’t know what network they’re planning to run over, 
what the level of support for the networking protocols is, etc. Unfortunately, it is very hard to work 
networking into a completed game; we really want to be working on it from the start. Without the 
necessary information from Sony, networking is likely to be implemented in a non-optimal way, or 
squeezed out of the schedule. 


Brief Overview 


The Network Features describes a basic architecture of network engine that may be used for building a 
vatriety of games with network capabilities or local/global networks oriented. This document attempts to 
detail basic principles of engine, general interfaces and optimization solutions. 


Goals 


This network engine scheme has 2 primary goals: 


> Get the current project out on time as full featured as possible. While this goal is obvious, it is 
stated here for completeness. 


> Be used for future Press Start/Interplay game development. 


Block Diagram 


The following block diagram gives a high level view of the network engine: 


High-level High-level : 
access access 
7 a 
7 a. 
ia “ 
pas 
High-level API High-level API 
access access 
7 7, 
we 7 
‘ t aa t i ras 
Low-level API Low-level API 


Transport 
layer 


Transport 


layer 
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Communication Communication 


SDK SDK 


Figure 1 Network Engine Diagram 
Description of Figure 1 
Solid bold arrow - communication environment (direct cable, local area network, wide area network, etc). 
Solid thin arrow - links between internal components of network engine. 
Dotted arrow - links between network engine and external environment. 
White blocks - internal components of network engine. 
Grey blocks - external environment. 
Black blocks - third party software. 


Detail structure of blocks will be explained below. 


Third party software — communication SDK | 


Third party software is used as the low-level communication layer of the network engine. Unfortunately 
we still don’t have any descriptions of communication SDK for PSX2, but we hopes this SDK will provide 
hardware-independent access to network. 


Hardware classification: 
» Direct cable | 
> Modem | 
> LAN adapter 


Transport layer 


This layer needs for supporting of network protocols. Transport layer could be an original or third party 
software (such WinSock SDK or Sony Libraries). 


Protocols classification: 
> TCP/IP | 
» Sony proprietary protocols | 


Low-Level API 


Low-level API provides easy access to capabilities of network engine. The level could be used for direct 
connection between users or as client part for third party server. 


ERRNO OpenChannel ( CHANNEL& chu ); 
ERRNO SetMode ( MODE mode ); 

STATUS GetStatus (CHANNEL chml ); 

bool Connect( ADDRESS address ); 
ERRNO Listen (int num_of_port ); 


ERRNO Accept (CHANNEL chil ); 
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ERRNO Send (CHANNEL chnl, DATA data, UINT size ); 
SIZE Receive (CHANNEL chnl, DATA& data ); 

void CloseChannel (CHANNEL chul ); 

Channel 


#define CHANNEL void* // channel for connection 


Press Start, Inc. 


Channel is an abstract connection for the network engine. You can send and receive data using a channel, 


and is a full-duplex connection. 


Error Code 


#define ERRNO int // code of error 


Type of connection 


typedef enum 
{ 
MODE_TCP, 
MODE_UDP, 
MODE_UDP_CORRECTION 
} MODE; 


Status of connection 


typedef enum 

{ 
STATUS_READ, 
STATUS_WRITE, 
STATUS_ERROR 

} STATUS; 


Using low-level API 


11/3/99 


// safe connection 


// fast connection, data lost possible 
// fast connection w/error correction 


// type of connection 


// current status of channel 
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High-Level API 


High-level API provides an access to client-server capabilities of network engine. The level could be used 
for organization of multiplayer game in the local/global networks. 
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Audio and Data Streaming 


We are likely to have to stream textures and/or audio sounds from the CD. It is possible we will also 
have to stream geometry data, but we hope to avoid that complication in this game. 


Risks - Medium 

The risks are mostly associated with the unavailability of the hardware, and the possible necessity of 
streaming both sounds and textures at (approximately) the same time. The sooner we get the hardware, 
the sooner we'll know. 
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Menu/UI Implementation 


A game menu is just another scene (or level) in the world. By taking this approach, our menus may be a 
very simple collection of text objects that appear on a background, or they may be as complicated as 
having a garage setting, where you pick items like tires, engines and the like by selecting them from items 
in the garage. As an extreme, you may even wish to have a chorus line of mice dancing to the garage 
radio in the menu scene, and have a particle effect of smoke coming up from a cigarette in the garage. 
Menu complexity is only limited by the limitations of the rest of the engine specification. 


Menus are constructed using Menu AI objects that are built in 3D Studio or manually constructed in a 
text file for testing. Artists build a “3D menu scene,” which may contain any object that the normal 
engine is capable of processing. By selecting that the AI type of an object is “menu”, the artist is 
presented with options for the objects that allow them to set the “focus” to the input controller, as well as 


wow 


define what it’s action is if the user selects it— such as “start game”, “pause”, or “pick truck type.” 


Menus are not limited to only menu objects. A menu is a separate scene which either overlays (on top of) 
or replaces the current scene. 


The differences between a menu and a normal scene are: 


> Menu AI objects are used where selectable options are wanted. 


» Overlay menus (on top of a scene) must coexist in the world and be positioned in front of the 
camera in order to be seen. 


> Control of the player’s controller is taken over by the menu. 


> Some or all of the normal game logic must “freeze” during a “pop up” menu. Sony standards 
will be implemented, as is normal. 


Adding Menu AI to an object in a scene 


As with any object in a scene, the artist places a “controller” node on the object. One of the characteristics 
of the controller node is which AI script is associated with the object. When the artist indicates that an 
object in a scene is a “menu scripted object”, the options for a menu object are made available to the artist. 


Examples of the options of a menu object are: 
> Select Level 
Start Level 
Restart Race 
Select Truck 
Initial focus (which object is selectable when the menu first pops up). 


Next menu item to get focus 


VV VV V WV 


Previous menu item to get focus 


Controlling a menu during run time 


Since menus are just another scene, all the normal game logic is used to control a menu. All objects are 
the same type of 3D objects that are used in the rest of the game. The following are exceptions to the 
normal game logic. These exceptions are not an issue where the menu is actually a stand-alone level, 
such as the screens that select which track you will race on before the race starts. 
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Overlaying a menu 


If the menu is an overlay type, such as a boring list of text that appears like a pop-up window, then extra 
logic is required by the running game. The game must be paused, control reprioritized to run the 
appropriate menu tree (see controller priorities), and after the selection is made the game must be un- 
paused (or whatever the menu option dictates). In an overlay menu, the objects must also position 
themselves in front of the camera. 


Taking control of the player’s game controller 


During the time that a menu is present, the normal scene AI is not ran due to a priority change. Since the 
controller input is scanned by the AI, control is automatically removed from the player to control the 
normal game. At the same time, the menu objects which have their own AI are now evaluating the game 
controller for input. 


Passing menu selections back to the engine 


When a menu is displayed, a message is sent down the controller tree telling each object that a menu is 
being shown. This allows the controller labeled with “starting focus” to be the only menu AI object 
excepting game controller input. The message that starts the menu may also override the focus item id if 
so desired, such as when backing out of a chain of menus where the last object selected should still be 
selected when the “menu stack is popped”. 


The user may then make selections such as “next menu item”, which will change the focus to the next 
menu item (which the menu object stores). If the user presses the “accept” key to select a menu item, 
then it depends on the attributes of the menu item as to what the action is. If the menu item had the 
“start game” attribute, then the selected menu object would call the start game function (part of 
programming the menu object Al). If the menu item had the “select level” option, then the AI would do 
that call, which may be to update the menu item’s text, or to show a new 3D object such as a track. 


Menu object text 


Text on a menu object may take two forms. The first is that it is geometrically drawn, where it is not text 
at all but a 3D object. The second form is a 3D object with a “text texture” on it. This is a texture where 
the engine places text in the texture. The texture is already mapped to the object, so the text appears. For 
the items that have “text textures” on them, the text will come from a file that contains all localization text 
within it. The Menu AI object will have the intelligence to be able to either scale the texture or the menu 
object depending upon a flag the artist may set when placing the menu object in the world. 


Risks — Low 

The only foreseeable risk is a frame rate problem if a menu becomes extremely complicated 
geometrically, and is meant to overlay (while displaying) any area in the current level. Since the levels 
will be filled with geometry until total load breaks the 60hz limit, overlay menus will have to remain 
simple. If this problem occurs it will only happen in an overlay menu, and it can be fixed by simply 
reducing the complexity of the menu (to the worst case of just text selection). 
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Input Handling 


The input device is the PlayStation analog dual shock controller. We’ll be polling the controller multiple 
times per frame so that we can respond quickly to user actions. (When you're traveling 120mph, it 
counts.) 


We plan to create an interface between the stream of low level data coming in and the high level game 
commands — “Accelerate”, “Turn right” etc. The game engine will be able to simply look at the high level 
commands, rather than trying to interpret the low level data itself. This will allow us to easily change the 
mappings between sequences of key presses and high level commands, or even to move to a different 
controller. 


Force feedback? 
Controllers supported? Analog/Digital — third party controller support? existing playstation controller 
support assumed.... no other information is necessary 


Risks — Low 
It’s the same device we've used in past PlayStation games, and is unlikely to present many unknowns or 
problems. 
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Low Level Hardware Interface 


At the moment there are several not-particularly well defined areas where we need to interface with the 
hardware. These include DMA, the MPEG decoder, and deciding how to split up the processing to 
optimally use each of the PlayStation’s processors. 


steal information from Interplay document 


Risks ~ Medium 

Until we have hardware and have a better sense of exactly how all the pieces of the game fit together on 
the hardware, there’s just no way to know how hard these things are going to be. Maybe we’ll be able to 
use Sony-supplied DMA functions. Maybe we'll have to write our own. Maybe there are tricks and 
gotchas that we just can’t know about yet. The hardware interface is not anticipated to be an 
insurmountable task, but until we have hardware we just can’t know for sure. 
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Art Tool Chain 


The art tool chain comes in four pieces - 

a) Press Start’s 3D Studio Calliope™ plug-in, our object and world builder. 

b) Texture converter, from TARGA to whatever we decide to store textures in 

c) Animated texture converter, from TBD animation package (such as Debabelizer Pro) to 

proprietary format. 

d) Binary converter, from output of 3D Studio w/plug ins to proprietary format. 
Of these four, the plug-ins to 3D Studio and the Binary converter are the most involved, and will be 
described here. 


The idea behind Calliope is to give the artist or production assistant maximum control of the action of the 
objects in the game. For instance, instead of the artist coming to the programmer and telling him/her 
that “this car ought to have this type of tires”, Calliope will read a car-characteristic template when an 
object of type “car” is created. Calliope will display a dialog box on the screen containing, among other 
things, a pull down with options for the type of tire. (See Tool Chain Supplement for picture). The tire- 
type information will be saved as part of the instance of that car object, and can be loaded into the game 
without intervention of the programmer. 


The feature described above is the “object template”. The full list of features is described below: 
> Object template: Allows artist/PA to input object-specific information that is later used in the 
game. 


> Minimum # of polygons: Since we will be using a progressive mesh for many of our object 
LODs, we allow the artist to specify the minimum number of polygons to which the object may 
be decimated. 


>» Gems: These space-partitioning regions (See Scene Builder section of this document, or Scene 
Builder Supplement) must be created by hand. Although hand building is tedious, it only has to 
be done once, and should give us a more efficient structure than standard BSP schemes. The plug 
in allows the artist/PA to both define the gems and to define the list of other gems visible from 
the gem being modified. 


> Sound events: Although 3D Studio does not support sound, we can allow it to support sound 
events in animations. This plug in looks for “sound notes” during an animation sequence. These 
sound notes contain the name of the associated sound file, the volume at which to play the 
sound, the pitch, and other sound characteristics. They also define where a sound begins and 
ends during the animation. 


>» Export inhibiter nodes: Some objects in the 3D Studio database are used for reference only, and 
should not be exported (for instance, a gun in a character’s hand, where the artist is trying to get 
the arm position of the character correct for holding a gun, but the type of gun he/she is holding 
changes depending upon in-game parameters.) Inhibiter nodes prevent any geometric objects 
below them in the hierarchy from being exported. 


> Collision spheres and/or collision rectangles: The Artist or PA will be able to attach collision 
geometry to anode. The collision geometry will be hierarchical, with leaves containing lists of 
associated polygons. Collision geometry for a parent object is assumed to contain collision 
geometry for sub-objects. 
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The Calliope™ plug-in to 3D Studio will be set up to output the following four files: 
>» SDF -Scene Description File: Contains gem hierarchy info. 


>» GDF -Gem Description File: Contains the actual gem data structures, visibility lists, and 
references to instance data. Also contains object templates, and object property information, but 
not the geometry or animation data. 


» MDF - Model Data File: Contains actual geometry data for one object template. Model data 
includes triangle based models, lights, collision geometry, trigger objects, and splines for path 
finding. 

>» ADF - Animation Data File: Contains animation information for the objects in the associated 
MDF. The MDF and the ADF contain the same object hierarchy. 


Binary Converter 
The output of 3D Studio (with Calliope™ plug-in) is ASCII data. We do this for a number of reasons: 


> It’s human readable, and we should be able to quickly find any problems in the output 
» It’s game and platform independent, and can be reused for any other game. 


» This also allows us to hand-generate data to proceed with engine development until the tool 
chain is complete. An additional step, the Binary Converter, is required to put the data into final, PS2 
specific format. 


Clearly, the Binary Converter takes the output of 3D Studio (the geometry, region, animation and 
template data) and converts it into our own format. However, it also does some non trivial processing, 
explained below. 


In addition to the standard conversion, the binary tool is responsible for the following: 
> Creation of progressive meshes for LODs 
> Creation of shadow maps (See ‘Shadows’ in section SP-FX) 
» Division of region leafs into octrees. 
> 


Error checking of data with meaningful error messages that allow the artists to find problems in 
the data without consulting an engineer. 


Risks ~ Medium 

This is a big task, and many things depend upon it. The risk here is not so much whether we will be able 
to create this tool, but whether unexpected difficulties creating the tools will significantly affect other 
parts of the schedule. To limit this risk, certain critical tasks (physics, collision detection, some rendering 
and car AI) will be started without the tool chain in place. This will cause some duplication of effort and 
some extra integration work, but will ensure that the project keeps moving. The binary tool is already in 
the state of reading the data required to build scenes with characters (without animation data or spline 
information as of yet). Although a tedious process, we will be able to read in hand-generated scenes and 
models without textures as soon as the engine is capable of reading the output of the binary converter. 
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Particle System 


The particle system will allow the caller to specify the type of particle (smoke, sparks, sand, etc), the 
number of particles to create, the size of the particles, the lifetime of the particles, a geometry from which 
the particles are emitted, the texture and/or color of the particles, and a callback function to invoke when 
the particles die. We can also generate objects that have their own AI from the particle system (how 
about raining trucks?) 


We can choose to have particles collide with objects, but processing of this will be limited to very specific 
situations as doing otherwise could add a substantial amount of performance risk. In rain, particles will 
be emitted from the tire sources. Normal rain bouncing off the hood of a car is not specific enough to 
require an individual drop to splash — so another effect (probably some form of particle emitter on the hood) 
will be desirable. 


Particles will be represented within the Scene Manager as a Particle Volume, which will have its own 
collision information and will manage the activities of the individual particles within it. We will not 
attempt to collide with individual particles — things will collide with the particle volumes. 


The “type” of the particles is an attempt to characterize different particle behaviors. Smoke wafts out and 
up, sparks just go out, and sand travels in a nice parabolic curve. By allowing us to specify the base 
behavior of the system, plus a finite number of particle parameters, we should be able to simulate many 
different particles. 


Risks — Low 

There are two issues — one that we will create too many particles for us to render, and two that we will 
have trouble finding time to process the particles. Both problems can be solved simply by creating fewer 
particles. It remains a task for the designers to find the appropriate trade off between speed and 
appearance. 
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FMA 


Full Motion Animation (or cinematics) are pre-defined animation sequences that are used at special times 
during the game. For instance, if the player causes an avalanche to occur, or gets caught up in a tornado, 
we may want to stop the standard flow of the game and play cinematic sequences. 


FMA is implemented by defining special FMA actor, camera and director objects for each FMA scene. 
These objects have their own controllers, animation sequences and AI, and are treated within the game 
loop just like other objects. (Also note that these objects may well share geometric models with the rest of 
the game). The motion of both actors and cameras within the world is defined by splines - we make no 
attempt to do on the fly, realistic physics in these sequences. The director object is responsible for 
switching between cameras at the appropriate time, and for stopping the FMA prematurely if necessary 
(say, for instance, if the player got tired of watching it). 


Other objects in the world must be aware that the FMA is occurring, and their actions may either be 
suspended or modified so that they do not ruin the effect of the FMA. For instance, if the player is at the 
top of a cliff having just triggered an avalanche, and the FMA sequence is running, we really don’t want 
to allow another car to come along during the sequence and push him/her off the cliff. That would be 
considered very poor sportsmanship on the part of the game designers). 


Risks - low 


The largest risk is overloading memory with too much animation data, as during the design of an FMA 
sequence the artist may want to add new animation to existing characters in a scene. For example, the 
artist may decide that upon entry into the Voodoo Village that on Halloween (is the PlayStation 2 aware 
of the date?) the inhabitants of the village gather together and perform a 5 minute “Las Vegas” style 
dance act, complete with spotlights, musical accompaniment and 200 trained parrots performing acts of 
acrobatics. Clearly the amount of extra animation data for this is prohibitive. This will be handled by 
changes in design to fit within memory requirements. 
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Memory Card 

Saving and loading of games is restricted to saving the current tracks and secrets that have been 
unlocked, as well as the configuration of the player (such as what cars are owned, which options are 
owned, and how much money the player has). Simply said, the state of the game before the next race is 
ran is what is saved. Preference options such as sound on/off will also be saved. 


steal stuff from interplay document? 


find things in Knockout Kings source code? probably stick existing API in here... :) 


Risks — Low 


Even in the face of all the unknowns about the NVRAM system that Sony is using, this is not expected to 
be a high-risk task. 
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Virtual File System 


In order to allow us the maximum flexibility in laying out our files, and to assure that we aren’t bitten by 
a badly written third party driver, we plan to concatenate the files in the game into one large file and use 
our own TOC to access the actual files within the virtual file. 


This system will also be able to compress and decompress data in the virtual file, and also will allow the 
same file to exist in multiple places in the virtual file. (This second condition is necessary on a CD/DVD, 
where you need to minimize seek time.) 


Using a public domain implementation of ZIP — for file access and compression. 


Art department adds files to an existing ZIP file. Benefit — is that ZIP is supported by all platforms and is 
commonly available. 


Risks - Low 
This technology is straightforward and has been written many, many times. 
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Memory Management 


insert information from code - API 


DRAM Management 


The DRAM memory manager will be a standard pointer based memory manager. We will be writing our 
own memory manager to get maximum flexibility and to ensure we can fix any bugs that might crop up. 


Risks — High 
This is a traditional ugly problem, and will most likely be one that we rework or add to more than once as 
we gain experience on the PS2 hardware. 


SPU-RAM Management 


Based on the same code as the DRAM manager, the SPU-RAM manager handles RAM for the Sound 
Processing Unit. This is not a sound-cache. 


VRAM Management 


VRAM, a 2 dimensional structure, is considerably more difficult to manage than standard 1-dimensional 
DRAM. To make things even a bit more difficult, the PS2 allows VRAM “overlays” for textures with 
fewer than 16 bits for pixel — 2 four-bit textures, for instance, may start at the same location in VRAM but 
have different byte offsets, so they are interleaved through each other. 


We cannot possibly fit all the textures we will use in this game, or even in one level of this game, into 
4MB of VRAM. We can allocate certain areas of VRAM to certain types of things — terrain, car textures, 
shadows, but we’ll ultimately be swapping textures in an out from main memory. 


Risks — Medium 


The issues here are memory fragmentation and running out of memory. Since we are not using a handle 
based system, we cannot re-arrange memory to fit the available space, nor can we throw out “lower 
priority” memory to make room for something more important. If we have problems with 
fragmentation, we will implement memory pools that will allocate memory in different regions based 
upon the size or usage of that memory. Problems with sheer memory size will have to be addressed by 
compression, cutting down on the amount of data in the game, streaming data off the CD, and careful 
coding. 


We will implement a “high water mark” function so that we have an idea of the maximum amount of 
memory that we’ve been using. 


Fragmentation should be kept at a minimum as the majority of the data in a scene is instanced when the 
scene is first loaded. The scene manager will insure that all regions and object templates (along with the 
template object data) are loaded with no holes. 
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Geometry Compression 


We are attempting to avoid streaming geometry off the CD/DVD for this game. Since we are not going 
to get a dev station with a CD/DVD until fairly late in the game, we're trying to avoid as much streaming 
as we can. 


However, if we don’t have streaming we need to fit all the geometry for one level into DRAM. Current 
back of the envelope calculations show that we expect between 2 and 3 times as much geometry data as 
we can fit into the machine. (Guessing 1 million polygons at 30+ bytes apiece, = 30 + MB). The artists are 
hoping to fit the world into fewer polygons (500K), but even so we should plan for some geometry 
compression. 


Possibilities for compression include the use of higher-dimensional representations for cars, and storing 


vertices as 16-bit fixed point offsets from the center of the object. Other possibilities are to provide 
traditional file compression algorithms to the geometry and decompress as required. 


Risks — Medium 


(TBD) 
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Sound & Music 


Our goal is a portable, High Level API, User Interface, and Tool Stream. Ideally, the only code that 
should have to be significantly re-written when porting is the Low Level Audio Code. 


High Level API 


User Interface 


Tool Stream 


These tools must manage all of the different data types used to produce audio. The goal is a system that 
does not require re-building (compile and link) code whenever a sound is added, removed, or changed. 


Low Level Audio 


Risks — Medium 


The goals or re-useable code and a tool stream not requiring code re-builds when changing sound 
resources may make performance optimization difficult. 


Our Windows environment is resource rich in ram and hard drive space. The PS2 will have relatively 
limited ram, and all streamed audio will have to come from the CD. These differences add a degree of 
uncertainty when porting from Windows to the PS2. Not having sound capability on the first 
development stations also adds a considerable risk. 
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Instant Replay 


Instant replay will be accomplished via saving a stream of user input and starting the race from the 
beginning in a know state. 


Risks — Low/Medium 


There are two known risks. The first (the size of the memory card) is what gives this task a Medium 
status. A lot of input can occur during a race. We will require the ability to store all filtered input as a 
stream for playback. The second risk is a software discipline risk. We must insure that we can recreate 
all events based upon random number generators identically each time the same race is ran. This is 
accomplished by having each random event keep it’s own seed, and use methods to pick the seeds so that 
changes in events such as changing the camera view to not interrupt a predictable pattern during a 


replay. 
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Special Effects 


Shadows 


At the time of writing, it has not been decided how we will handle shadows. Several schemes are under 
consideration, and the choice will finally be made based upon machine limitations, such as availability of 
VRAM. 


Static shadows can be produced by the creation of shadow maps within the binary tool. These maps can 
work ina variety of ways. 


Shadows, Reflections, Tornado, weather, clouds 


11/3/99 ** PRESS START CONFIDENTIAL *** Page 17 of 65 


Technical Design Document 
Mud, Sweat & Gears: Off-road Madness Press Start, Inc. 


Major Milestones (completely TBD) 


Milestone 1 - PC Test bed, Simple Track 


Dates 
22? -22? 


Description 

Since we do not have PlayStation hardware, we have been forced to begin development on the PC. The 
first milestone is thus entirely PC based, and focuses on the high-level game structure and tool chain, 
which should be platform independent. 


In this milestone, we create and import a simple car that travels around a simple track. The car either 
responds to user input, or, if it is driving independently, follows a bezier based path. The car also makes 
a simple sound (“au-oo-gah”) as part of its AL. 


Most of the coding for this task is “under the covers” — not visible to the user. The tool chain from 3D 
Studio to the game must be complete enough that we can create and export a simple scene and a simple 
car. The car and track must be loaded from our binary files and registered with the Scene Manager. The 
Scene Manager will then call through the car AI template to move the car. The Scene Manager will also 
register the camera and the light, and will call their respective Als to modify their behavior. Rendering 
and physics are primitive at this point — we render gouraud shaded triangles, and do not calculate forces 
based on uneven road surface. The interfaces for the Memory Manager and the input module are 
defined, but the implementation is PC based. 


Test for completeness 

Car and scene can be defined 3D Studio, output with plug to in ASCII format, run through binary 
converter and imported into the scene manager. Car responds to user input (gas, brakes, steering) in 
expected ways. Car follows bezier curve when moving independently. Camera follows car around track. 
Car AI causes horn sound to play. 


Risks 
Minimal. We do not anticipate any technical problems. 


Milestone 2 - Move code to PlayStation, additional track complications 


Dates 
222? 


Description 

The end of each milestone marks an obvious point to move our development efforts to the target 
hardware. Obviously, the sooner we have the target hardware the sooner we can resolve uncertainties 
various uncertainties and technical difficulties involved with that hardware, but we do what we can 
without. 


We hope to have enough development stations to move over to PlayStation development at the 
beginning of Milestone 2. If this is not the case, various tasks associated with PlayStation specific 
development (VRAM management, texture caching, input handling, integration with PS2 specific 
renderer) must be pushed out to the following milestone. 
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Because of the dependency on PlayStation hardware, this milestone is subdivided into Milestone 2a — 
PlayStation only tasks, and 2b — Platform independent tasks. 


Milestone 2a — PlayStation specific tasks. Existing code runs on PlayStation development system (with 
possible exception of sound code, which may have to be stubbed out since the hardware does not yet 
support sound). Textures can be loaded into texture cached, transferred to VRAM, managed by VRAM 
memory manager, and displayed on car and terrain. 


Milestone 2b — Platform independent tasks. Scene manager has been updated to handle animations 
queued for events, transparencies (?). Binary converter creates shadow maps and environment maps. 
Collisions implemented, and basic physics is now complete. 3D Studio Calliope™ plug ins now allow 
artists to define Al parameters and progressive meshes. 


Test for completeness- Two cars (one controlled by simple AI from previous Milestone), one controlled by 
user, move around track. Track is bumpy, cars respond to track unevenness as expected by physics. Cars 
can collide with one another, respond in appropriate physical way. LOD/progressive mesh information 
as defined by the users of 3D Studio appears in the game. 


Risks 


Milestone 3 — Basic Game play complete! | 
First Stage in staged delivery process | 
Cars interact with terrain to create ruts. Multiple vehicles. NPC car AI updated so the cars actually 
interact with you, some trying to push you off the road. Particle systems, dynamic lights. Cars take 
damage which effects their performance. Game can be loaded and saved. (?? Networking??) 


Test for completeness 
Risks 


Milestone 4 — First Level complete! 
Second Stage in staged delivery process 

At this point w 
All effects 


Milestone 5 — First Level. 


Somewhere in milestone 4 we expect the artists to have finished the first level for the track. Milestone 5 
will be integrating that artwork into the game, and resolving any special game play complications on that 
level. 

Test for completeness — 

One level can be played in its entirety. 


Milestone 6 — 

At this point it the order of the tasks becomes unclear. After the first level is done, we expect to have feed 
back There are three major tasks for us at this point — Filling out the game shell, resolving any issues on 
the t 


Tests — Scene manager. (Check task list for what we said it was going to do( 
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Task Breakout 
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Appendix A 


Right Threaded Binary Trees and Tree Traversal 


The workhorse of the scene manager is the “Right Threaded Binary Tree”, and one function named 
“treeWalk”. Just about every aspect of the scene manager relies on this tree structure and the one walk 
function. The benefit of this is that the core of the scene manager becomes “bullet proof” very quickly 
after implementation, as it’s used over and over again. This also results in a very small code footprint. 


An “RTree” (note that the node is also called an RTree in the code definition) is a binary tree where the 
nodes point to their parent, child, and their right-hand sibling (Knuth Vol 2). As opposed to a normal 
binary tree where each node has two children. The RTree is very adept at certain “surgery” tasks, which 
are relied on heavily in the scene manager. The tree is a depth first tree, which means that the child of a 
node (and it’s children) is processed before the sibling. 


Press Start has decided to lower the risk of development and choose C over C++ due to the unknown 
status of the Playstation C++ compiler prior to launch. The tree traversal scheme used is definitely an 
object oriented concept, so the first task is to create a “node object” that has single inheritance 
characteristics. Below is the definition of an RTree node that is used as the “base class” of all other node 


types. 


typedef struct tagRTree 

{ 
struct tagRTree* pParent; 
struct tagRTree* pSibling; 
struct tagRTree* pChild; 

}RTree; 


Example: Implementing a tree of “color nodes” based upon RTree. 


Suppose that we want to make a tree of nodes that contain a color. The new color node definition would 
look as follows: 


typedef struct 


{ 
RTree tree; 
int color; 
}ColorNode; 


The C language guaranties that when the structure is built that the data in the structure will be placed in 
the same order as defined in the file [X6J3 committee standard]. This means that casting the ColorNode 
to type RTree allows us to access the tree linkage information in a standard way, allowing code to link 
and traverse these trees regardless of the extra data contained within the tree. 


“Walking” (or traversing) trees who’s nodes are “inherited” from the RTree type can be accomplished 
with one function prototyped as follows: 


typedef enum 


{ 
treeContinue, 
treeHalt, 
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treeIgnoreChildren 
}treeRet; 


void treeWalk(RTree* pNode, treeRet (*callback) (RTree*,void*), void* pParam) ; 


Fortunately, you don’t have to look at the prototype of this function very much, as staring at things like 
this too long can really hurt your head. What this function does is take 3 arguments: pNode is the node 
to start the traversal at (typically the root of the tree, but does not need to be); “callback” is a pointer to a 
function that takes an RTree pointer and a void pointer (used like IpParam in a window’s callback) and 
returns a “treeRet” condition. The last argument is the parameter that will be passed into the callback’s 
parameter argument. An example follows to help clear this up. 


Example: Traversing a tree of “color nodes” (from above) to count the number of red nodes in the tree. 


Assume that we already have a tree built out of “color nodes” (this paper does not cover how to build 
trees with functions such as AddChild or AddSibling). We first write a callback function that will just 
check the node pointed to and increment a counter if the node is red. 


treeRet IsRed(RTree* pNode, void* pParam) 


{ 
ColorNode* cNode = (ColorNode*)pNode; 


If (cNode->color == RED) 
(int*)pParam += 1; 


return treeContinue; 


Now in the body of a function, we could count the number of red nodes as follows (assume the tree of 
colorNodes is named pColorRoot): 


foo () 
{ 


int colorCount = 0; 
treeWalk(pColorRoot, IsRed, (void*) &colorCount) ; 


printf(“Amount of red nodes = %d\n”,colorCount) ; 


The walk function’s behavior is to traverse the tree starting at the given node, and for each node in the 
tree it calls the callback function, passing the callback the current node being traversed, and the void* 
parameter that was given in the walk function. The result is that IsRed will be called for each node in the 
tree, and each time it’s called the node will increment the integer value pointed to by the pParam pointer. 
Upon return from treeWalk, colorCount will contain the count of “red nodes” in the tree. 


By inheriting the RTree type, we can make trees of controllers, trees of Gem Bounding objects, templates 
and instances, and have a general purpose method of tree surgery and traversal. 
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